pantheon-opencode 1.6.0-beta.1 → 1.6.0-beta.11

package/src/skills/auto-continue/SKILL.md

@@ -18,16 +18,16 @@ Disciplined automatic continuation through multi-step tasks. Eliminates unnecess
 
 ---
 
-## Mandatory Gates (ALWAYS STOP)
+## Risk-Proportional Gates
 
 | Gate | Trigger | What happens |
 |---|---|---|
-| **GATE 0 — Agora Gate** | Agora outputs `AWAITING_APPROVAL` OR `## 🏛️ Agora Council` synthesis block appears | **HARD STOP.** Do not call any tool, do not continue any todo, do not suggest next steps. Wait for user to type: APPROVE / REQUEST CHANGES / DISCARD. "ok", "yes", "sure", "continue" are NOT valid. |
-| **GATE 1 — Plan Approval** | Athena generates a plan | User confirms scope before code is written |
-| **GATE 2 — Phase Review** | Themis reviews implementation | User sees changes before next phase |
-| **GATE 3 — Git Commit** | After each phase is approved | User controls git history; no auto-commit |
+| **GATE 0 — Explicit Council** | User explicitly invokes council and it returns `AWAITING_APPROVAL` | Stop and follow the approval the council requests; do not launch a council automatically for ordinary implementation. |
+| **GATE 1 — Plan Approval** | A plan was requested or scope/risk makes planning necessary | Ask before implementation only when the plan introduces a material choice or risk; omit this gate for a bounded, clear fix. |
+| **GATE 2 — Risk Review** | Auth/security, data/schema/migration, API contract, production configuration, or other material risk | Themis review and human approval before sensitive or irreversible action. For a trivial, isolated, reversible edit, provide a concise result instead of manufacturing a review phase. |
+| **GATE 3 — Git / External Action** | Commit, push, merge, production deploy, destructive operation, global configuration, or broad permission change | Always stop for explicit human approval. Full-auto never authorizes these actions by implication. |
 
-> **Agora is always GATE 0**: any response containing `AWAITING_APPROVAL` or a `## 🏛️ Agora Council` block overrides all auto-continue rules.
+An explicit `AWAITING_APPROVAL` from an invoked council remains a hard stop. Authentication/security and data/schema changes retain their review and approval gates even in full-auto.
 
 ---
 
@@ -36,32 +36,35 @@ Disciplined automatic continuation through multi-step tasks. Eliminates unnecess
 **Continue automatically when:**
 - Next todo is a direct consequence of the current one
 - Action is reversible (file edits, tests, linting)
-- Scope is within the approved plan
+- Scope is within the user's explicitly authorized task (a prior plan is not required for a small clear fix)
 - No new ambiguity has emerged
 
 **Stop and ask when:**
 - A todo requires a decision not covered by the plan
 - An unexpected error changes the approach
 - A dependency is missing or broken
-- A task would exceed remaining `steps` budget
+- Remaining context is too thin to carry the task through — write an explicit handoff instead
+- The task reaches a sensitive gate in the table above; full-auto does not override it
 
----
+### Full-auto Authorization
+
+Full-auto may continue only within a task and scope the user explicitly authorized. It may run reversible edits and proportionate verification; it must stop for auth/security, data/schema changes with risk, destructive or global changes, broad permissions, deploy, push, or merge. Never infer permission to expand the scope from a full-auto request.
 
 ---
 
 ## Implementation Pattern
 
 ```
-1. Create todos for all steps at start
-2. Mark first todo in_progress
-3. Complete work → mark completed immediately
-4. Mark next todo in_progress → repeat
+1. Create a checklist only for multi-step work; a one-step fix needs no todo ceremony
+2. Use native todo operations only when a todo-write tool is visible in the active session; otherwise keep the checklist explicit in the conversation
+3. Mark work complete in the available checklist as soon as it is done
+4. Do not claim that the native todo list was updated when no todo-write tool is exposed
 5. Do NOT ask "should I continue?" between clear steps
-6. Stop at Gate 1, 2, or 3
+6. Stop at any applicable risk gate; do not require a plan/review gate for a low-risk edit
 7. After gate approval, resume with next todo
 ```
 
-**Never batch-complete todos.** Mark each completed as soon as done.
+**Never batch-complete checklist items.** Mark each completed as soon as done; do not imply a tool call occurred unless it did.
 
 ---
 
@@ -70,7 +73,7 @@ Disciplined automatic continuation through multi-step tasks. Eliminates unnecess
 - [ ] Previous step completed successfully (tests pass, no errors)
 - [ ] Next step is within approved plan scope
 - [ ] No new blocking issues emerged
-- [ ] `steps` counter has sufficient budget remaining
+- [ ] Remaining context can carry the next step, or an explicit handoff will be written
 
 ---
 
@@ -89,9 +92,9 @@ Phase N complete. Summary:
 
 ### Cooldown Rules
 1. **Between parallel waves (no dependency):** No cooldown needed — wave results are independent
-2. **Between sequential waves (with dependency):** Always run cooldown — dependencies may have changed context
-3. **After Themis review (GATE 2):** Cooldown is mandatory — review findings may change the plan
-4. **Session reuse check:** Before starting next phase, check if a specialist session from a previous phase can be reused (see session-goal skill)
+2. **Between sequential phases:** Summarize when dependencies or risk changed; skip ceremony for one-step work
+3. **After required Themis review:** Reassess findings before continuing
+4. **Session reuse check:** Reuse a prior specialist session only when it reduces real context duplication
 
 ### Abbreviated Cooldown
 When auto-continuing between sequential non-gated phases, the cooldown is abbreviated to one line:
@@ -104,6 +107,14 @@ Only expand to full cooldown when hitting a mandatory gate.
 
 ## Timeout & Retry Enforcement
 
+Delegate through the root `subagent` tool observed in the Beta 10 runtime. `task()` is
+host/API terminology, not an assumed root tool; call shape and background support are
+runtime-dependent. Prefer synchronous dispatch unless the active schema exposes background
+and the host provides an observable completion notification. Do not assume `task_status`,
+`cancel_task`, or board-based tracking/recovery tools are available. When no completion
+mechanism is observable, use synchronous dispatch or state the limitation; do not claim
+that jobs are being tracked or recovered.
+
 When a delegated agent does not respond in time, enforce the timeout policy defined in
 `src/instructions/zeus-timeout-retry.instructions.md`.
 
@@ -125,7 +136,7 @@ When dispatching, set the expectation explicitly:
 
 ### Timeout Tracking Table
 
-Maintain a mental table of in-flight delegations:
+Maintain an in-context (not persistent/native) checklist of delegations when needed:
 
 | Agent | Started | Timeout | Status | Partial OK? |
 |-------|---------|---------|--------|-------------|
@@ -163,19 +174,25 @@ Should I now run the migration tests? [waiting]
 Session state is **not** file-based. It lives in **pantheon-persistence** under the
 `checkpoint:<slug>` namespace and is cleaned up automatically by a 4h TTL.
 
-Write state with `context_save(slug, key, value, session_id=...)` and read it back with
-`context_get(slug, "latest", session_id=...)`. Capture `session_id` from the first `context_save`
-of the session and reuse it for the rest of the session, so the `latest` pointer survives
-compaction.
+Use checkpoints only when `context_save` and `context_get` are explicitly
+present in the active session's tool list. If unavailable, do not attempt a
+checkpoint or guess a session ID; carry the handoff in the normal response.
+
+When available, call `context_save` with `content=JSON.stringify(state)` and an
+explicit `session_id`. A successful save needs no immediate `context_get`; read
+only when resuming or when the save result is uncertain. Reuse the same session
+ID so the `latest` pointer survives compaction. `state` must be an object — never pass a bare string as `content`: its
+`goal`/`phase`/`delegations`/`heartbeat` values are objects and `tail` is an array.
+`goal` is optional; when unset, omit the key rather than passing a string placeholder.
 
 ### Heartbeat Check
-- If `context_get(slug, "heartbeat")` returns a checkin older than 300s, log a stall warning and resume
-- Write a heartbeat after every anti-stall recovery action
+- Check heartbeat only when checkpoint tools are available and the workflow needs a durable resume.
+- Write a heartbeat after anti-stall recovery only when the current session exposes checkpoint tools.
 
 ### Checkpoint Rules
-1. Save a checkpoint before **every** delegate dispatch and after every agent returns
-2. Include current phase, turn count, and remaining tasks
-3. On resume: `context_get(slug, "latest")` restores the most recent checkpoint
+1. Save checkpoints only for long-running/multi-phase work, context-loss risk, or substantive parallel work — not a one-off command or bounded fix
+2. Include current phase and remaining tasks when a checkpoint is warranted
+3. On resume, read the latest checkpoint only with a known session ID; otherwise request the missing handoff context.
 
 > Do not create `heartbeat.json`, `checkpoint-<N>.json`, or `session.json` under
 > `.pantheon/deepwork/`. That file-based mechanism is retired — TTL handles cleanup, and reading
@@ -189,10 +206,10 @@ Configurable gates for different platforms and risk levels:
 
 | Gate | Default | Auto-Approval Condition |
 |------|---------|------------------------|
-| GATE 0 — Council/Plan | Always Ask | N/A — always requires human |
-| GATE 1 — Plan Approval | Always Ask | Plan matches acceptance criteria + no risks flagged |
-| GATE 2 — Themis Review | Ask by Default | Auto-approve if: Themis APPROVED + no CRITICAL/HIGH issues + coverage ≥80% |
-| GATE 3 — Git Commit | Never Auto | N/A — always manual |
+| Council | Only when explicitly invoked | Never auto-start a council for ordinary implementation |
+| Plan approval | Only for requested or risk-required plans | Skip for bounded, clear work |
+| Themis review | Required for sensitive/material changes | May omit for trivial isolated edits; never auto-bypass required findings |
+| Git / external actions | Never Auto | Commit, push, merge, deploy, destructive/global changes require explicit approval |
 | Deploy | Always Ask | N/A — always requires human |
 | Destructive DB Ops | Always Ask | N/A — always requires human |
 
@@ -205,8 +222,8 @@ auto-continue:
   idle_stall: 120            # seconds before stall detection
   idle_pause: 300            # seconds before auto-pause
   gates:
-    plan_approval: always_ask
-    themis_review: auto_approve_if_clean
+    plan_approval: when_required_by_scope_or_risk
+    themis_review: required_for_sensitive_or_material_changes
     git_commit: never_auto
     deploy: always_ask
     destructive_ops: always_ask

package/src/skills/code-review-checklist/SKILL.md

@@ -52,11 +52,11 @@ biome check --write --unsafe <files>
 - [ ] Proper file sizes (<300 lines)
 
 ### Testing
-- [ ] Unit tests written
-- [ ] Coverage ≥80%
-- [ ] Integration tests for workflows
-- [ ] Edge cases tested
-- [ ] Error conditions tested
+- [ ] Tests cover the changed behavior where meaningful; documentation/format-only changes do not need invented tests
+- [ ] Apply an explicit repository coverage threshold only when measurable and relevant to the changed code
+- [ ] Integration tests where the change crosses workflow boundaries
+- [ ] Relevant edge cases tested for the changed behavior/risk
+- [ ] Relevant error conditions tested
 
 ### Security (OWASP Top 10)
 - [ ] Input validation present