codex-governance-publish

name	codex-governance-publish
description	Use for `E:\See-you-more-than-her` or `E:\codex-governance` publish/report runs that mention zhongshu plans, existing PR updates, local launcher APIs, or "submit all local changes" without broad extra checking.
argument-hint	[repo-path] [mode]
disable-model-invocation	true
user-invocable	false
allowed-tools	["Read","Grep","Glob","Bash"]

codex-governance-publish

Use when:

1. The user wants to commit/push current repo changes and update an existing PR.
2. The workflow mentions report_zhongshu_plan, report_result, zhongshu_inbox, or readonly inbox monitoring.
3. The task is in E:\See-you-more-than-her or E:\codex-governance and needs strict repo-boundary handling.

Do not use when:

1. The user asked for code changes unrelated to publish/report flow.
2. The task is a generic GitHub publish without the local governance launcher or zhongshu API workflow.

Inputs / context to gather:

1. Confirm target repo path and branch with git status -sb and git branch --show-current.
2. Read AGENTS.md first if present. Read other docs only if the task needs them.
3. Check current PR state with gh pr view --json number,url,title,headRefName,baseRefName,state,isDraft.
4. If zhongshu APIs are involved, inspect /api/status before posting a plan so model choices and launcher version are known.

Procedure:

1. Confirm scope lock.
   • If the user named E:\codex-governance, do not edit E:\See-you-more-than-her.
   • If the user named the main repo, do not assume standalone-repo rules apply.
2. Identify workflow mode.
   • plan-only: generate and POST the first-stage zhongshu plan, then stop and wait for confirmation.
   • publish-with-checks: run the requested tests/py_compile/governance checks before commit/push.
   • publish-no-checks: skip tests and move directly through commit/push/PR update after scope confirmation.
3. Build the zhongshu plan when needed.
   • POST to http://127.0.0.1:6211/api/report_zhongshu_plan.
   • Include session_id, summary, and assignments[] with department, task, model, files, verify, reason, model_reason, selected.
   • Use gpt-5.5 unless the current user explicitly asks for another model.
4. Run the publish path.
   • Stage exactly what the user requested.
   • Commit current changes.
   • Push to the current branch.
   • Re-check PR state with gh pr view.
5. Report completion.
   • POST result JSON to http://127.0.0.1:6211/api/report_result first.
   • Use mailbox write only if HTTP fails.
6. If the user requested readonly monitoring:
   • Query http://127.0.0.1:6211/api/zhongshu_inbox?id=<session_id>.
   • Report status and unread count.
   • Stop the monitor if there is no actionable result.

Efficiency plan:

1. Read only AGENTS.md, git status, PR state, and the exact governance files touched by the task.
2. Do not open git diff after every small edit. Use task-specific verification first.
3. Reuse known working commands:
   • gh pr view --json ...
   • python tools/codex_governance/codex_governance.py
   • python -m unittest ...
4. Stop early in plan-only mode after a successful report_zhongshu_plan response.

Pitfalls and fixes:

1. Symptom: unknown model: gpt-5.4-mini.
   • Cause: model not in launcher whitelist.
   • Fix: query /api/status and prefer gpt-5.5; do not use older model families unless the current user explicitly asks for them.
2. Symptom: git push fails with connection reset.
   • Cause: direct GitHub path unstable.
   • Fix: retry with HTTP_PROXY, HTTPS_PROXY, and if needed ALL_PROXY set to http://127.0.0.1:7890.
3. Symptom: .git/index.lock blocks commit.
   • Cause: transient lock from another process.
   • Fix: verify and retry; do not delete the lock by default.
4. Symptom: zhongshu_inbox?peek=1 returns 400 Bad Request.
   • Cause: endpoint is unreliable in this environment.
   • Fix: use zhongshu_inbox?id=<session_id> instead.
5. Symptom: unrelated file changes appear in diff/status.
   • Cause: user-owned edits or another terminal.
   • Fix: do not revert automatically; confirm before discarding or overwriting.

Verification checklist:

1. Correct repo boundary respected.
2. Branch and PR state confirmed with gh.
3. Required checks run only if the user or workflow mode requires them.
4. Push succeeded or failure cause captured.
5. report_result HTTP POST succeeded, or mailbox fallback was used intentionally.
6. If monitoring was requested, report whether zhongshu_inbox?id=... showed actionable results.