I notice that we have a --json global flag for all the entire repo commands

where, I reckon it is only implemented inside entire repo mirror list. Validate where it is implemented and move away from global flag

1w ago·16m·57 calls

What was wrong

--json was a persistent control-plane flag (addControlPlaneFlags, corecmd.go), inherited by every subcommand of repo/org/project/grant. It was implemented broadly (all list/get/create verbs) — not just mirror list. Real defect: 9 side-effect verbs inherited it and silently ignored it.

Fix (structural, your pick)

• Dropped --json from persistent addControlPlaneFlags; kept --insecure-http-auth persistent (all commands build a client).
• Added local helper addJSONFlag(cmd); wired it onto the 20 commands that honor it.
• jsonRequested() unchanged.

Result

• repo clone --json → Error: Invalid usage: unknown flag: --json (loud, not silent no-op).
• repo clone --help → no --json. Help honest.
• repo mirror list --help → still shows --json. Honoring commands unchanged.

Verification

• New test TestControlPlaneJSONFlag_OnlyOnHonoringCommands — walks all 4 group trees, locks the 27-command matrix (drift in either direction fails). RED before, GREEN after.
• Full cmd/entire/cli package tests pass.
• gofmt clean; golangci-lint v2.11.3 clean (0 issues).
• Live binary confirms reject + help behavior above.

Two notes

1. mise run lint fails in your env — stray golangci-lint v1.64.8 in ~/.local/share/mise/installs/go/1.26.4/bin shadows the mise-pinned v2.11.3. Pre-existing, not my change. Ran v2 directly → clean.
2. Files touched: corecmd.go, org.go, project.go, repo.go, repo_mirror.go, repo_mirror_collaborators.go, grant.go, + test file & one stale test comment.

No commit made — say "ship it" when ready.

Ship Changes

Commit current changes, push to remote, and update the PR.

Step 1: Analyze changes

1. Run git diff --stat and git diff to understand what changed
2. Run git status to see untracked files
3. Run git log --oneline -3 to match the repo's commit message style

Step 2: Commit

1. Stage only the relevant changed/untracked files by name (never git add -A or git add .)
2. Write a concise commit message that focuses on the "why" not the "what"
   • If draft is provided, use it as the commit message
   • Otherwise, draft one from the diff
3. Commit. If hooks fail, diagnose and fix — do NOT use --no-verify

Step 3: Push

1. Check if the branch tracks a remote: git rev-parse --abbrev-ref --symbolic-full-name @{u}
2. If not tracking, push with -u origin <branch>
3. If tracking, just git push
4. If push is rejected (remote has new commits), pull with rebase first then push

Step 4: Update PR

1. Find the open PR for the current branch: gh pr view --json number,body,title
2. If no PR exists, skip this step and inform the user
3. Compare the current PR body against the new changes:
   • If the changes are within the existing PR scope, update the description to reflect the current state
   • If the changes are additive or a follow-up, add a PR comment summarizing what was just pushed instead
4. When updating the PR body, preserve the overall structure but refresh the summary bullets and test plan
5. When adding a comment, keep it concise — bullet points of what changed and why
6. Before making any PR update (description edit or comment), show the user the exact text you plan to post and ask for their approval. Do NOT post until they confirm.

Rules

• Never commit files that look like secrets (.env, credentials, tokens)
• Never force push
• Always show the user what was committed and the PR URL when done

Confirmation Note

I have confirmed the root cause of the issue. It's a pre-existing flaky test on main, not related to my --json change.

Why it failed

Failing test: TestRunInvestigateConfigPicker_QuorumExceedsAgents ...

The flake sequence: ...

Options

1. Just re-run test-core — it's flaky, likely goes green (doesn't fix the underlying bug).
2. Fix it here: drop t.Parallel() from the two override-setting tests (lines 37, 85), honoring the documented contract. One-line-each, safe, but scope-creep on a focused PR.
3. Fix separately on its own branch/PR, re-run this PR's CI meanwhile.

Which do you want? I'd lean #2 with a note in the PR — it reliably unblocks and the fix is trivially correct.