feat(pi): Babysit foundations — shared PR/push extraction, five GitHub tools, sandbox lifetime

.agents/plans/pi-babysit-mode.plan.md

@@ -0,0 +1,68 @@
+---
+name: pi-babysit-mode
+overview: Add optional Babysit Mode to Create PR so a newly opened, ready-for-review pull request can request bot reviews, fix trusted feedback and diagnosable checks in bounded rounds, push one commit per fixing round, reply and resolve host-side, and return an accurate partial-success report.
+todos:
+  - id: shared-foundation
+    content: Keep the shared GitHub tools, strict PR snapshot helpers, push hardening, redirect protection, and E2B lifetime plumbing
+    status: completed
+  - id: create-pr-surface
+    content: Remove standalone Babysit and add the Create PR toggle, required reviewer mentions, bounded rounds, forced ready PR behavior, and conditional outputs
+    status: completed
+  - id: create-pr-composition
+    content: Capture the new PR number, destroy the creation sandbox, run the internal Babysit continuation in a second sandbox, and aggregate results without persisting review content to memory
+    status: completed
+  - id: initial-review
+    content: Preflight and pin the new PR, post initial reviewer comments, wait for later bot activity, and re-request review after every pushed fix
+    status: completed
+  - id: partial-results
+    content: Preserve the created PR and accurate zero/false counters for no-PR, startup, budget, and later partial-success outcomes while keeping cancellation exceptional
+    status: completed
+  - id: docs-and-tests
+    content: Update Pi documentation and tracking, remove stale standalone tests and types, add Create PR composition coverage, and run the repository gates
+    status: completed
+isProject: false
+---
+
+# Pi Create PR Babysit Mode
+
+Branch `feature/pi-babysit`, originally branched from `feature/pi-search`.
+
+## Current shape
+
+Pi has three top-level modes: Create PR, Review Code, and Local Dev. Babysit is an optional Create PR continuation, not a standalone mode and not part of Review Code.
+
+When enabled, Create PR:
+
+1. Requires one or more comma-separated bot review comments.
+2. Creates the PR ready for review.
+3. Destroys the creation sandbox.
+4. Strictly preflights and pins the new PR, posts the initial reviewer comments, and starts a second sandbox against that PR head.
+5. Waits for trusted bot activity and required checks, fixes actionable feedback in bounded rounds, pushes at most one commit per round, replies, resolves, and requests review again.
+6. Preserves the PR URL, branch, counters, booleans, and stop reason after partial success.
+
+The Create PR phase can load and save conversation memory. The continuation receives the selected task, skills, model, and search configuration but always starts with `initialMessages: []`; its review-derived report is never written to conversation memory.
+
+## Security and orchestration decisions
+
+- Only complete threads whose comments are all from an owner, member, collaborator, or GitHub App bot are actionable.
+- Check reads fail closed. Required failures and pending or missing contexts block a clean result; optional failures remain agent-visible.
+- GitHub API writes are host-side and revalidate the pinned PR at phase boundaries.
+- Pi receives no GitHub credential, GitHub tool, or Sim integration. Repository extensions, prompt templates, repository skills, and project trust are disabled.
+- The token-bearing clone and push still run in a previously agent-controlled root sandbox. This is accepted Create-PR-equivalent residual risk, not absolute credential isolation.
+- Create PR and its continuation use sequential sandboxes. E2B billing continues during inter-round waits; Daytona remains unchanged.
+- Reviewer mentions are mandatory when the toggle is enabled. Each entry is posted once initially and after every successful fixing push.
+- User cancellation throws. Once a PR exists, other startup or runtime failures return a partial-success report.
+
+## Non-goals
+
+Fork PRs, merge-conflict resolution, force-push or history rewriting, changes under `.github/`, Greptile-score gating, and fixing the pre-existing shared `PREPARE_SCRIPT` commit bug remain out of scope. A base-branch conflict is reported but does not prevent review-fix pushes.
+
+## Validation
+
+- Focused Pi regression suite: 259 tests passed.
+- Full monorepo regression suite: 14,800 tests passed.
+- Changed TypeScript files pass Biome, and `git diff --check` passes.
+- API validation, monorepo boundaries, client boundaries, realtime pruning, migration safety, React Query, Zustand, utilities, skills sync, and agent-stream documentation checks pass.
+- The full type-check remains blocked by pre-existing SDK mismatches in `apps/docs/app/api/chat/route.ts` and `apps/sim/providers/anthropic/core.ts`.
+- The full lint check reaches only generated, untracked Playwright artifacts under `apps/sim/e2e/.runs`; the implementation files are clean.
+- Contract generation checks that depend on the sibling Copilot checkout cannot run because `/Users/billleoutsakos/sim2/copilot/copilot/contracts/` is absent. Independent generated checks pass.

.agents/skills/reviewed-development/IMPLEMENTATION.md

@@ -0,0 +1,139 @@
+# Implementation Mode
+
+Implement the requested change completely, validate it in proportion to risk,
+and subject the current result to repeated independent review before delivery.
+
+## 1. Confirm the implementation contract
+
+Read the accepted plan, current user request, relevant repository instructions,
+and current branch state. Establish:
+
+- Objective, scope, non-goals, and definition of done.
+- Files and systems expected to change.
+- Tests, rollout, documentation, and manual acceptance required.
+- Whether commit, push, branch, or PR operations were explicitly authorized.
+- Existing user changes that must be preserved.
+
+If the plan has become stale, verify the current repository and adapt it
+carefully. Escalate only decisions that materially change product behavior,
+risk, or destructive outcomes.
+
+## 2. Re-ground in current code
+
+Inspect the implementation paths and nearest established patterns before
+editing. Do not rely solely on summaries or the plan's file list. Check for
+changes made since planning, hidden coupling, generated artifacts, migration
+rules, and repository-specific validation commands.
+
+Create a concise execution checklist for substantial work. Implement in
+coherent phases, keeping only one phase actively changing the repository at a
+time.
+
+## 3. Implement the smallest complete solution
+
+- Follow existing architecture, naming, contracts, and ownership boundaries.
+- Address root causes instead of suppressing failures or adding broad
+  workarounds.
+- Keep security, authorization, data integrity, secret handling, and cleanup
+  fail-closed.
+- Preserve backward compatibility and safe rollout ordering where versions can
+  overlap.
+- Avoid unrelated cleanup, speculative abstraction, duplicate helpers, and
+  infrastructure without a demonstrated need.
+- Update tests and documentation alongside the behavior they protect.
+
+Do not weaken invariants or tests merely to obtain a passing result.
+
+## 4. Verify continuously
+
+After each meaningful phase, run the cheapest relevant proof. Before review,
+run the complete validation justified by the change, such as:
+
+- Focused unit and integration tests.
+- Type checking, linting, formatting, generated-file, and boundary checks.
+- Migration, deployment, or compatibility verification.
+- Browser or end-to-end tests through the project's supported orchestrator.
+- Manual checks that cannot be automated.
+
+Read failures as evidence. Fix introduced problems, distinguish unrelated
+baseline failures explicitly, and do not report a check as passed unless it
+actually ran successfully.
+
+## 5. Self-review the current diff
+
+Before commissioning reviewers:
+
+- Compare the implementation with every plan requirement.
+- Inspect the full diff, including generated and staged files.
+- Check edge cases, negative paths, concurrency, partial failure, and cleanup.
+- Confirm tests prove observable behavior rather than implementation details.
+- Remove accidental duplication, debugging output, dead code, and unnecessary
+  complexity.
+- Verify no credentials, local artifacts, or unrelated user changes entered the
+  diff.
+
+## 6. Commission independent reviews
+
+Generate two complete, neutral prompts from the current task, plan, repository,
+implementation, diff, and verification evidence according to the
+independent-review protocol. Launch two fresh reviewers concurrently when
+possible.
+
+Do not ask reviewers to validate the parent's preferred approach. Ask for their
+genuine assessment of correctness, security, pattern fit, test quality,
+maintainability, redundancy, overengineering, operational safety, and complete
+coverage of the user's objective.
+
+Reviewers must inspect the repository directly and remain read-only.
+
+## 7. Triage, fix, and re-verify
+
+Independently verify every finding:
+
+- Fix valid issues with the smallest clean solution that matches repository
+  patterns.
+- Push back on false positives or harmful suggestions with concrete evidence.
+- Resolve contradictions by examining code and requirements, not by choosing
+  the more confident reviewer.
+- Re-run all checks affected by substantive changes.
+- Resume each reviewer separately with the current implementation and the
+  response to its findings. Continue until it accepts the resolution or the
+  protocol's unresolved-disagreement stop condition applies.
+
+Do not tell the other reviewer or reviewers in later cycles what an earlier
+agent found.
+
+## 8. Re-review the current implementation
+
+Generate fresh prompts describing only the current objective, code, diff, and
+evidence. Begin another independent review cycle with an entirely new pair.
+Never reuse reviewers from an earlier cycle.
+
+If this review causes substantive edits, reviewers disagree materially, or
+meaningful uncertainty remains, run one additional fresh pair after
+re-verification, subject to the protocol's three-cycle cap. The final accepted
+review must apply to the implementation being delivered.
+
+## 9. Delivery gate
+
+Do not declare completion until:
+
+- The implementation satisfies the current plan and definition of done.
+- Relevant automated checks pass, with manual-only checks identified.
+- No Critical, High, or Medium concern remains unresolved without an explicit,
+  evidence-backed decision.
+- The final substantive revision has been independently reviewed.
+- The diff is scoped, clean, and free of secrets or temporary artifacts.
+
+Commit, push, or create a PR only if the user's request authorized those
+mutations. Follow repository-specific git and PR procedures rather than
+inventing a generic release flow.
+
+Report concisely:
+
+- What changed and why.
+- Verification performed and outcomes.
+- Material issues found and corrected.
+- Evidence-backed pushbacks.
+- Remaining manual actions or known limitations.
+- Commit, branch, or PR details when delivery was authorized.

.agents/skills/reviewed-development/INDEPENDENT_REVIEW.md

@@ -0,0 +1,133 @@
+# Independent Review Protocol
+
+This protocol defines how the working model commissions independent reviews. It
+is not a reviewer prompt template.
+
+Every reviewer in this protocol is a separate subagent launched by the working
+model, not a perspective role-played in the parent conversation. In Cursor, use
+the `Subagent` tool. A fresh reviewer means a new subagent invocation and agent
+ID; a follow-up within the same review cycle resumes that subagent's existing
+conversation.
+
+## Generate prompts from the current task
+
+Generate each reviewer prompt after inspecting the current repository and
+artifact. The prompt must be self-contained because a fresh reviewer has no
+access to the parent conversation.
+
+Include the context that materially affects the review:
+
+- A concise overview of the relevant codebase and architecture.
+- The user's actual objective, constraints, non-goals, and definition of done.
+- The current plan, diff, branch, or exact files to inspect.
+- Established local patterns and sources of truth the work should follow.
+- Important data, security, migration, deployment, or compatibility boundaries.
+- Verification already performed, with exact commands and outcomes when useful.
+- The areas changed and the behavior they are intended to provide.
+
+Generate the prompt for the task at hand. Do not copy a fixed generic prompt or
+fill a mechanical template with shallow substitutions.
+
+## Keep every review independent
+
+- Begin each independent review cycle with two fresh reviewers, preferably from
+  different model families with strong reasoning capability. Honor models
+  requested by the user.
+- During that cycle, resume each reviewer separately to resolve its findings.
+  Never reuse either conversation in a later independent review cycle.
+- Do not tell a reviewer whether it belongs to the first, second, final, or any
+  other review pass.
+- The initial prompt in a cycle must not include findings, verdicts, responses,
+  or changes from earlier cycles.
+- Do not tell reviewers what conclusion to reach or imply that defects must
+  exist. Acceptance is a valid result.
+- Use the same generated prompt for both reviewers by default. Differ only when
+  a model requires different technical context or tooling instructions, while
+  keeping both reviews broad and neutral.
+- Ask reviewers to inspect repository evidence directly rather than trusting the
+  implementation summary.
+- Keep reviewers read-only unless the user explicitly requested a separate
+  implementation attempt.
+
+## Ask for a genuine broad review
+
+Ask each reviewer to judge the artifact as a whole and report anything it
+genuinely dislikes. The review should consider, where relevant:
+
+- Correctness, requirement coverage, and edge cases.
+- Security, privacy, data integrity, authorization, and secret handling.
+- Concurrency, failure recovery, cleanup, and partial-success behavior.
+- Compatibility with existing architecture, conventions, and nearby patterns.
+- Missing, brittle, redundant, or misleading tests.
+- Unnecessary complexity, duplicated logic, speculative abstraction, and
+  overengineering.
+- Performance, operational, migration, rollout, and CI consequences.
+- Documentation and manual steps required for safe ownership after merge.
+
+This is a review surface, not a quota. Explicitly tell reviewers that acceptance,
+many findings, or anything between are valid outcomes. They must not optimize
+for finding count or manufacture criticism.
+
+## Severity and response format
+
+Require an explicit verdict and order concrete findings by severity:
+
+- **Critical**: credible security compromise, data loss, destructive rollout,
+  or another issue that makes proceeding unsafe.
+- **High**: likely correctness failure, unmet core requirement, serious
+  architectural mismatch, or major operational risk.
+- **Medium**: material robustness, maintainability, test, performance, or
+  pattern-consistency issue that should be resolved.
+- **Small**: non-blocking polish or a narrowly scoped improvement.
+
+Each finding must include:
+
+- Concrete repository evidence, preferably a file and line or exact behavior.
+- Why it matters and when it can fail.
+- The smallest appropriate correction or decision needed.
+
+If no substantive defect exists, the reviewer should say that plainly rather
+than manufacture criticism.
+
+## Triage without deference
+
+The working model owns the result. For every finding:
+
+1. Verify it against the repository and the user's objective.
+2. Fix it when it is correct and within scope.
+3. Push back when it is incorrect, conflicts with requirements, or would add
+   unjustified complexity; retain the evidence for the final summary.
+4. Re-run affected verification after substantive changes.
+5. Resume that reviewer with the current artifact and an evidence-based account
+   of what changed or why the finding was rejected.
+
+Handle each reviewer independently; do not use one reviewer's opinion to steer
+the other. Continue the exchange until the reviewer accepts the resolution or
+has no substantive concern. Ask it to re-inspect the current artifact rather
+than merely approve the parent's explanation.
+
+Agreement does not mean obeying the reviewer. A valid endpoint may be a fix or
+an evidence-backed pushback that the reviewer accepts. Follow-ups within a
+review cycle are not capped: continue the separate exchange with each reviewer
+until the concern is resolved. The three-cycle cap limits newly created reviewer
+pairs, not follow-up messages in an active cycle.
+
+Do not forward this cycle's triage history to reviewers in later cycles. Their
+initial prompts describe only the current artifact and current evidence.
+
+## Review completion
+
+Run two independent review cycles by default. Each cycle begins with exactly two
+newly created reviewers, and each reviewer reaches resolution through the
+follow-up process above. Track cycle count only in the working session; never
+expose it in reviewer prompts.
+
+Run one additional cycle only when the later cycle causes substantive changes,
+reviewers disagree on a material issue, or meaningful uncertainty remains.
+Never exceed three cycles or six fresh reviewers for one planning or
+implementation task.
+
+After the third cycle, stop even if a reviewer still disagrees. Report the
+unresolved concern, evidence, attempted resolution, and available decision to
+the user rather than launching more reviewers. The final reviewed artifact must
+be the artifact being presented or shipped, not an earlier revision.