pantheon-opencode 1.5.2 → 1.6.0-beta.10

package/src/skills/agent-coordination/SKILL.md

@@ -34,8 +34,8 @@ Route tasks to optimized agents based on category instead of specifying agents m
 
 ```
 1. User describes feature
-2. @athena creates PLAN with phases and agents
-3. User approves PLAN (GATE 1)
+2. @athena returns the complete PLAN to Zeus (no approval prompt from the child session)
+3. Zeus displays the full PLAN in the main conversation, then asks the user to approve it (GATE 1)
 4. Zeus dispatches agents to phases (parallel when possible)
 5. Each agent: TDD cycle → writes IMPL artifact
 6. @themis reviews all phases (GATE 2)
@@ -67,6 +67,11 @@ All phase outputs go to `.pantheon/memory-bank/.tmp/`. See `skill: artifact-mana
 
 ## Safety Gates
 
+For every requested plan, Gate 1 is not satisfied by a child-agent approval
+question or a link to a hidden artifact: the complete plan must be visible in
+the main conversation before Zeus asks for approval. If the user requests
+changes, Zeus presents the complete revised plan and repeats Gate 1.
+
 | Gate | When | Why |
 |------|------|-----|
 | **GATE 1** | After PLAN | User confirms scope |

package/src/skills/artifact-management/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: artifact-management
-description: "Structured artifact trail for feature implementations — plans, implementations, reviews, and decisions."
+description: "Structured artifacts for planned, multi-phase, or materially risky implementation work."
 context: fork
 globs: []
 alwaysApply: false
@@ -8,7 +8,7 @@ alwaysApply: false
 
 # Artifact Management
 
-Structured artifact trail system for documenting feature implementations. Defines what, where, and how agents produce phase outputs.
+Structured artifact trail for planned, multi-phase, or materially risky implementation work. Artifacts are not a prerequisite for simple fixes or read-only investigation.
 
 ---
 
@@ -55,6 +55,13 @@ All ephemeral artifacts live in `.pantheon/memory-bank/.tmp/` — gitignored and
 
 > **Zeus does NOT generate artifacts.** He orchestrates agents that generate them.
 
+## Proportional Use
+
+- Create PLAN/IMPL/REVIEW artifacts for planned multi-phase work or when risk, auditability, or an explicit request needs a durable phase trail.
+- A bounded, reversible fix should be investigated only as far as needed, implemented, verified with focused checks, and returned as a concise summary. Do not create PLAN, IMPL, or REVIEW artifacts for it.
+- Read-only lookup or trivial discovery needs no DISC artifact; use one only when findings are broad enough to be reused or drive a material decision.
+- The absence of an artifact never waives Themis review or human approval for auth/security, data/schema/migrations, production-impacting work, or sensitive actions.
+
 ---
 
 ## Templates
@@ -103,9 +110,9 @@ All ephemeral artifacts live in `.pantheon/memory-bank/.tmp/` — gitignored and
 
 ## Human Pause Points
 
-1. **After PLAN** → user reads `.tmp/PLAN-<feature>.md` and approves
-2. **After REVIEW** → user reads `.tmp/REVIEW-<feature>.md` and validates focus items
-3. **Before git commit** → user executes manually
+1. **After a required PLAN** → pause only when a material scope/risk decision needs approval.
+2. **After required REVIEW** → preserve auth/security/data/schema and other sensitive approval gates.
+3. **Before commit/push/merge/deploy or destructive/global action** → require explicit human approval.
 
 ---
 

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,28 +36,31 @@ 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
+1. Create todos only for multi-step work; a one-step fix needs no todo ceremony
 2. Mark first todo in_progress
 3. Complete work → mark completed immediately
 4. Mark next todo in_progress → repeat
 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
 ```
 
@@ -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,27 +107,18 @@ Only expand to full cooldown when hitting a mandatory gate.
 
 ## Timeout & Retry Enforcement
 
-When a delegated agent does not respond in time, enforce the timeout policy from routing.yml.
-
-### Behavior by Agent Role
-
-| Agent Role | Timeout | Retry Policy | Fallback | Timeout Parcial? |
-|------------|---------|-------------|----------|------------------|
-| Explorer (apollo) | 60s | 2 retries, exponential backoff | athena | ✅ Yes — partial results OK |
-| Implementer (hermes, aphrodite) | 180s | 3 retries, exponential backoff | talos | ❌ No — must produce artifact |
-| Reviewer (themis) | 120s | 2 retries, exponential backoff | zeus | ❌ No — must produce verdict |
-| Infrastructure (prometheus) | 300s | 2 retries, exponential backoff | hermes | ❌ No |
-| Hotfix (talos) | 30s | 1 retry, no backoff | hermes | ✅ Yes — one-liner fix OK |
+When a delegated agent does not respond in time, enforce the timeout policy defined in
+`src/instructions/zeus-timeout-retry.instructions.md`.
 
+**That file is the single authority** for per-role timeouts, retry counts, fallback chains, and
+whether partial results are acceptable. It is force-fed into every session via `AGENTS.md`; this
+skill is opt-in. Do not restate those values here — a copy in this skill is precisely what drifted
+out of sync with them. If a dispatch times out, read the role's row from the instruction file.
 
 ### Timeout Parcial (Partial Results)
 
-Timeout parcial is **only** allowed for read-only, independent agents:
-- ✅ @apollo (codebase search) — can return partial file list
-- ✅ @gaia (literature review) — can return partial findings
-- ✅ @talos (hotfix confirmation) — can return without fix if timeout
-- ❌ Never for implementers (@hermes, @aphrodite, @demeter) — must complete or fail
-- ❌ Never for reviewers (@themis) — must produce a verdict
+Whether an agent may return partial results is the **Partial Results OK?** column in that table.
+Only agents marked ✅ there may return partial — never implementers, never reviewers.
 
 **How to signal timeout parcial:**
 When dispatching, set the expectation explicitly:
@@ -167,69 +161,34 @@ Ready for Phase 2? Waiting for go-ahead.
 Should I now run the migration tests? [waiting]
 ```
 
-## Session Heartbeat
-
-Auto-save checkpoint every N turns (configurable, default 5).
-
-### Heartbeat File
-
-`.pantheon/deepwork/<slug>/heartbeat.json`
-
-### Heartbeat JSON Format
-
-```json
-{
-  "slug": "task-identifier",
-  "last_action": "2026-07-16T20:00:00Z",
-  "turn_count": 10,
-  "current_phase": 2,
-  "status": "alive | warning | stalled | paused | completed",
-  "next_action": "brief description of next planned action"
-}
-```
-
-### Heartbeat Rules
-1. Update every 5 turns minimum (by default)
-2. Contains NO context — only timestamps and counters
-3. Single file, always overwritten (not versioned)
-4. Used for quick "is this session alive?" checks
+## Session Heartbeat & Checkpoints
 
----
+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.
 
-## Checkpoint Persistence
+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.
 
-### Checkpoint File Structure
+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.
 
-Each deepwork task maintains:
-
-```
-.pantheon/deepwork/<slug>/
-├── PLAN.md                 # Immutable plan (created at start)
-├── STATUS.md               # Human-readable current state (updated every phase)
-├── heartbeat.json          # Lightweight ping (updated every N turns)
-├── checkpoint-<N>.json     # Full state snapshot (created at phase boundaries)
-├── session.json            # Session metadata (created at start, updated on stop)
-└── REVIEW.md               # Final Themis review (created at end)
-```
-
-### Checkpoint JSON Schema
-
-```json
-{
-  "slug": "string — unique task identifier",
-  "phase": "integer — current phase number",
-  "turn_count": "integer — total turns elapsed",
-  "timestamp": "string — ISO 8601 timestamp",
-  "context_hash": "string — first 8 hex chars of SHA-256 of STATUS.md",
-  "version": "integer — schema version (current: 2)"
-}
-```
+### Heartbeat Check
+- 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 at every phase boundary AND before any delegate dispatch
-2. Numbered sequentially (`checkpoint-1.json`, `checkpoint-2.json`, …)
-3. Keep last 10 checkpoints; archive older ones
-4. On resume: read the highest-numbered checkpoint for full state
+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
+> a file that nothing writes back returns stale state.
 
 ---
 
@@ -239,10 +198,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 |
 
@@ -255,8 +214,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