feat: add shared PR babysitting and idempotent thread sends

README.md

@@ -156,6 +156,19 @@ t3code models list --provider codex
 
 ## Existing threads
 
+### Shared PR babysitting helper
+
+The bundled helper gathers GitHub evidence, stores resumable state, and delivers change events through the same thread-message transport:
+
+```bash
+t3code babysit init --pr <PR-URL> --code-reviewer 'chatgpt-codex-connector'
+t3code babysit inspect --pr <PR-URL>
+t3code babysit status --pr <PR-URL>
+t3code babysit --help
+```
+
+Use the [babysit skill](skills/babysit/SKILL.md) for the commit-to-merge workflow and [helper reference](skills/babysit/references/helper.md) for evidence and delivery rules. The helper does not merge, post review requests, or register OS schedules. In T3, prefer its native PR watch; fallback `tick` runs through an OS schedule and only calls an agent when there is news. `wait` is limited to the active session. Delivery and handled-work acknowledgment remain separate.
+
 T3 thread ids are UUIDs, or ids that start with `thread:` when T3 minted them itself. Always pass the exact id.
 
 List threads across projects, or restrict discovery by project id or workspace:
@@ -217,6 +230,19 @@ printf '%s' "New findings that require more work..." \
 
 The send command does not report success from the dispatch alone. It waits until T3 records the exact message. Archived threads are rejected.
 
+For background event delivery, add an idempotency key and keep the exact message text unchanged on retries:
+
+```bash
+t3code --json threads send --thread <thread-id> --stdin \
+  --if-busy queue --idempotency-key <event-id> --no-start-desktop
+```
+
+Identifiers bind the thread, key, and exact text. Retrying the same combination reuses T3's durable command receipt or finds the message in the thread projection. Changing text, including whitespace, creates a different message even with the same key. Persist the rendered message before sending. Receipt replay does not establish that an agent completed the requested work; acknowledge handled events separately.
+
+Keys accept 1–200 letters, digits, dots, underscores, colons, and hyphens. Idempotent sends support `refuse` or `queue` (including the `reject` alias), and cannot change thread settings or steer/restart a turn. The normal JSON fields remain; keyed sends add `data.idempotency`. A projection-confirmed retry returns `deduplicated: "projection"`, `data.dispatch: null`, and delivery `already_delivered`. A dispatched send reports `deduplicated: "unknown"`, because T3 does not say whether it replayed a receipt.
+
+`--no-start-desktop` prevents background senders from launching T3 Code when it is unavailable. Settled threads still require the separate `--wake-settled` opt-in. A permanently rejected command must not be retried under a new key automatically; inspect the rejection before explicitly redelivering. At-most-once delivery depends on T3 retaining its receipt or message/run projection; it is not a guarantee across deletion of that history.
+
 A thread is busy while a turn runs or while queued messages wait for their turn. By default `send` refuses a busy thread with `THREAD_BUSY` and dispatches nothing; `error.details` names the running turn and the queue length. Choose another behavior with `--if-busy`:
 
 | `--if-busy` | Effect |

skills/babysit/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: babysit
+description: Commit intended changes, open or update a GitHub PR, and babysit reviews, CI, repairs, and merge verification. Use when the user invokes $babysit, asks to babysit a PR until merge, or asks to own the commit-to-merge workflow.
+---
+
+# Babysit
+
+Own the requested PR workflow through verified merge. Opening the PR or enabling auto-merge is not completion.
+
+## Scope and authorization
+
+Invoking this skill alone requests the full workflow through verified merge. Infer the target repository, branch or existing PR, and intended changes from the active task, conversation, and working tree. Begin at the first incomplete step. Do not require the user to restate the workflow or add instructions. Ask only when the target or intended scope cannot be determined safely from available context.
+
+This invocation, or a request to commit, create a PR, and babysit until merge, authorizes committing and pushing the intended changes, opening or updating the PR, posting task-related PR comments and review requests, fixing in-scope issues, and merging after all gates pass. Apply the same workflow to an existing PR when asked to babysit it until merge. Respect any narrower scope or explicit stop-before-merge instruction.
+
+Handle routine in-scope repairs without asking for permission again. Escalate missing permissions, required human approvals, legal agreements, paid usage, material scope changes, and decisions that require the user. Never sign a CLA, enable paid review credits, change branch protection, or use administrator bypass. Use another reviewer only if the user authorizes it. Do not spawn subagents unless the user explicitly requests them.
+
+## 1. Verify and commit
+
+- Read the repository instructions and follow its branch, commit, test, and merge conventions. Confirm the repository, intended base branch, and task scope.
+- Inspect the working tree and diff. Preserve unrelated work. Stage only intended files or hunks; exclude secrets and incidental output.
+- Run relevant tests, lint, type checks, and build using the repository's actual commands. For behavior changes, exercise the affected user journey or runtime path where feasible. Record commands, results, and anything not run.
+- Fix failures at their root cause. Add focused regression tests for bugs. Do not weaken checks or delete tests to obtain a pass.
+- Review the staged diff and create focused, descriptive commits. Use Conventional Commits unless the repository follows another format.
+- Push the task branch. Once the PR exists, verify that its remote head SHA matches the intended local commit. Investigate mismatches before proceeding.
+
+## 2. Open or update the PR
+
+- Reuse an existing PR for the branch. Target the correct base and keep the PR limited to the task.
+- Describe what changed, why, actual verification results, and any risks, migration requirements, or limitations. Never claim unrun tests passed.
+- Open ready for review only after local verification is complete. If work needs an earlier draft, complete verification before marking it ready.
+- With `gh`, use a body file for multiline PR descriptions and comments so actual newlines and literal text survive shell quoting.
+
+## 3. Wait for Codex review
+
+Use these user-provided settings unless the user updates them:
+
+| Setting | Value |
+| --- | --- |
+| Auto review | Enabled for Codex-enabled repositories |
+| Automatic trigger | On PR open |
+| Exhaustive code review | Enabled |
+| Paid credit use | Disabled |
+
+These settings are expected behavior, not proof that the current repository is connected or that a review has started.
+
+Let the automatic opening review run before requesting another review. Verify actual startup through live GitHub review activity or the review service's task state. If the opening review does not start, check access, configuration, and failure messages. After confirming no review is running or queued, request `@codex review` once if appropriate; repeated comments do not repair missing access or quota.
+
+Wait for the full exhaustive review, including review summaries, inline comments, and review threads. An early summary, completed check, or thumbs-up alone is insufficient while further findings may still arrive. Re-read comments and threads after completion. If the available evidence cannot establish full completion, keep the review gate pending and report the uncertainty; silence or an arbitrary quiet period is not proof.
+
+Associate all review evidence with the exact PR head SHA. Prefer review or task metadata that identifies the reviewed commit. Record the review/task identifiers, URLs, and completion evidence. When a comment or reaction lacks commit metadata, seek corroborating task evidence instead of assigning it to the current head from its timestamp alone. A clean review of an older commit does not approve a newer head.
+
+Use `t3code babysit inspect --pr <URL>` for deterministic evidence gathering. A submitted review on the current commit proves submission, not exhaustive completion. The helper deliberately leaves readiness unknown until corroborated completion evidence is recorded. After checking the review service's completed task and reviewed commit, run `t3code babysit record --pr <URL> --review-evidence --head <full-SHA> --url <task-URL> --note <completion-evidence>`. Never record that evidence from silence, an early summary, or an unbound thumbs-up.
+
+## 4. Repair and re-review
+
+- Inspect CI logs, review summaries, inline comments, and unresolved threads. Do not rely on the check rollup alone. Fetch all pages when listing review evidence and discussions.
+- Assess each finding against the code. Fix confirmed issues. Refute false positives with concrete evidence instead of changing code blindly.
+- Address actionable in-scope findings. Block merge on unresolved correctness, security, data-integrity, or required-review issues. Explain deferred non-blocking suggestions and why they do not block this PR. Escalate blocking issues outside the authorized scope.
+- Batch related repairs, add focused regression tests, rerun relevant checks, commit, and push to the same branch. Record the new head SHA and invalidate review evidence for the previous head.
+- Automatic review is configured for PR opening. Do not assume a repair push triggers another review. If no review of the new head is already running or queued, comment `@codex review` once. Record the request comment and head SHA so retries or resumed sessions do not duplicate it.
+- Wait for review and CI on the new head. Repeat until the final head has a completed review and no actionable blocking findings.
+- Do not resolve a thread merely to clear a gate. Record how the finding was fixed or refuted, including the relevant commit or evidence, and respect repository rules about who may resolve it.
+
+If Codex is rate-limited or unavailable, keep the PR unmerged and report the blocker. Rate limits are not approval. Do not enable paid credits, bypass review, or silently substitute another reviewer. If a reset or recovery time is known, retain the pending gate and resume at that time without repeatedly requesting reviews. A retry after an explicit failure is distinct from duplicating a running or queued review.
+
+Record successful local verification with `t3code babysit record --pr <URL> --tested <full-SHA> --result pass --command <verification-command>`. Bind every review request to its commit with `record --pr <URL> --review-request --head <full-SHA> --url <request-comment-URL>`. Check saved requests before posting another one. Use `decide --pr <URL> --finding <thread-ID> --decision fixed|refuted --evidence <explanation>` for assessed findings; a new or edited comment reopens the finding. These records support resumption and do not replace live GitHub verification.
+
+## 5. Babysit actively, with low noise
+
+Continue through verified merge or the user's narrower stopping point. A genuine blocker must name the missing gate and preserve resumable state. Do not write custom pollers or create a new conversation to deliver a wakeup.
+
+Initialize the shared helper once per PR:
+
+```text
+t3code babysit init --pr <URL> --code-reviewer "chatgpt-codex-connector"
+t3code babysit inspect --pr <URL>
+```
+
+Add `--thread <exact-T3-thread-ID>` when fallback delivery to the original conversation is needed. Determine that ID from the environment or inspect an explicitly identified thread; never guess between similarly titled conversations. A settled thread requires explicit continuing authorization before adding `--wake-settled`. State lives outside tracked source in `~/.babysit/v1/`; `status --pr <URL>` exposes the observations, pending events, and delivery errors. The helper never merges or requests a review itself. Read [helper.md](references/helper.md) when configuring fallback schedules, resuming an event, or interpreting unknown evidence.
+
+**Inside T3:** handle existing findings, link the PR, call the available `watch_pull_request` tool, and end the turn. Use the native watch first when its documented contract covers the required events. T3 owns future wakes. Do not also start a scheduled tick or an agent-owned polling process. On a wake, run a fresh `inspect`, act within the saved authorization, record evidence, and register/reconfirm the native watch before yielding again if the workflow remains pending. A native wake is news, not approval to merge. If native monitoring ends because the PR cannot be read, report that blocker and the actual monitoring status.
+
+**Fallback:** when native watch is unavailable, use the helper's `schedule-command --pr <URL>` to generate one OS-owned `tick` task. Inspect and run the generated registration command, save its identity/cancellation instruction, and verify the first successful tick observed the correct PR/head before calling monitoring active. A tick performs API reads without an LLM; it sends a wake only for a material change. It queues delivery to the original T3 conversation and does not launch T3 when closed. Stop any old watcher before changing mechanisms.
+
+**Without durable delivery:** use `wait --pr <URL> --timeout <duration>` within the active session. It makes no model call while sleeping. Disclose that this wait ends with the session; it is not durable monitoring.
+
+**On helper-delivered wakes:** run `inspect`, handle the event or record a concrete blocker, then `ack --pr <URL> --event <event-ID> --note <outcome>`. Delivery acceptance is not acknowledgment of handled work. Interrupted work stays unacknowledged in `status` and later wakes; deliberate recovery uses `wake --pr <URL> --redeliver <event-ID>`. Ambiguous delivery retries reuse the persisted text and event key. Rejected sends require diagnosis and explicit redelivery. Never start a second repair loop for the same PR.
+
+Keep unchanged observations silent and send brief updates for material changes. Unknown or incomplete evidence keeps the relevant gate pending. If the helper cannot express a gate, report the missing evidence rather than substituting an ad hoc parser.
+
+## 6. Merge only after final verification
+
+Immediately before merging, re-read the live PR state and verify every gate:
+
+- The head is the exact commit tested and reviewed.
+- Required checks have passed for the applicable commit or merge candidate. Missing, skipped, or cancelled checks are not automatically passing evidence; establish whether repository policy requires them and whether the applicable checks actually ran.
+- Codex has completed the full review of the final head, and comments and threads have been rechecked after completion.
+- No actionable blocking findings remain.
+- Required human approvals and repository rules are satisfied.
+- The PR is mergeable, and no new commits, comments, or review activity invalidate readiness.
+
+If the head changes, rerun affected checks and obtain Codex review of the new head. If the base changes, reassess integration and refresh checks as required by repository policy. Resolve in-scope conflicts, then verify and review the resulting head. Re-read the state after any readiness-changing event.
+
+Use the repository's merge method, defaulting to squash when no convention exists. Bind the merge to the verified head SHA where supported. Never use administrator bypass. Do not enable auto-merge before review gates are satisfied when branch protection does not enforce those gates. Continue monitoring while auto-merge or a merge queue is pending; enabling either is not completion.
+
+## 7. Prove completion
+
+Verify through GitHub that the PR is actually merged. Report:
+
+- PR URL.
+- Verified pre-merge head SHA and resulting merge commit SHA.
+- Local test results and final CI results, including material checks not run.
+- Final Codex review outcome and any required human approval outcome.
+- Remaining non-blocking limitations, if any.
+
+If GitHub shows the PR closed without merge, report that outcome accurately. A blocked handoff must name the unsatisfied gate, relevant evidence, the decision or external change needed, and the actual monitoring status.
+
+Stop any watcher and clean up only the task's branch or worktree, preserving unrelated work. Do not claim deployment or production verification unless separately requested and actually performed.
+
+Run `t3code babysit stop --pr <URL> --reason merged|closed|cancelled` when the workflow ends. Unwatch the PR in T3 or remove the one OS task using its recorded cancel command. A stopped helper performs no further API calls or deliveries.

skills/babysit/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Babysit"
+  short_description: "Own PR reviews, repairs, and verified merge"
+  default_prompt: "$babysit"

skills/babysit/references/helper.md

@@ -0,0 +1,23 @@
+# Shared helper
+
+Use the helper shipped with the modified t3code CLI: `t3code babysit --help`. Direct execution is also available at `skills/babysit/scripts/babysit.mjs` in that package. It needs Node and an authenticated GitHub CLI. Install the updated package before installing this skill; an older t3code CLI lacks the required commands and delivery flags.
+
+`init`, `record`, `decide`, `ack`, and `stop` update local state only. `inspect` reads GitHub and prints evidence. `tick` updates the observation and may deliver a message to the configured thread. `schedule-command` prints commands; it does not register a scheduler itself. Review the actual command help for flags and use `status` to inspect saved state.
+
+## Evidence
+
+Readiness is an aid to final verification, never merge authorization. A submitted review must match the full head commit and configured reviewer; it does not establish exhaustive completion. Record corroborating completed-task evidence explicitly. Code review and security checks remain separate. Unbound reactions, missing checks, incomplete pages, failed API reads, unknown mergeability, and stale tested commits cannot establish readiness. All unresolved findings need a recorded decision; later edits or new comments reopen them.
+
+## Durable delivery
+
+Each event has saved text and an identity. Ambiguous delivery retries use the same text/key. T3's command receipt confirms accepted delivery; the helper verifies the message through the CLI. It never automatically acknowledges work. `ack` is explicit, and a delivered event is not automatically resent. Check unacknowledged events when resuming a failed session; `wake --redeliver` is explicit recovery after inspecting the previous attempt.
+
+The CLI binds an idempotency key to its thread and exact text. Changing text creates a distinct delivery. Permanent rejections keep the event rejected until diagnosed and explicitly redelivered. Settled/archived/missing threads are not silently replaced with new conversations.
+
+## Scheduling
+
+Prefer the native T3 PR watch. For fallback, initialize with the exact delivery thread and use `schedule-command` to generate registration and cancellation instructions. Run one task per PR, retain the task identity, and verify a successful observation before reporting monitoring active. Scheduled ticks do not request periodic LLM turns. Windows fallback runs in the user's logged-in session; logout/shutdown stops availability, and a closed T3 app delays delivery. The helper does not launch T3 to deliver a background event.
+
+`wait` is an in-session fallback with a finite timeout. It is not a replacement for a durable task. When changing mechanisms, stop the old one to avoid duplicate wakes.
+
+After merge, closure, or cancellation, use `stop` and remove the task or native watch. Preserve state for resumption and audit. Do not delete unrelated task state or worktrees.