@gajae-code/coding-agent 0.1.1 → 0.1.3

package/src/defaults/gjc/skills/deep-interview/SKILL.md

@@ -60,11 +60,11 @@ Inspired by the [Ouroboros project](https://github.com/Q00/ouroboros) which demo
 
 ## Native Plugin Invocation Guard (Issue #3030)
 
-If this raw bundled skill is loaded by GJC's native skill loader through `/gajae-code:deep-interview` or `Skill("gajae-code:deep-interview")`, do not treat that path as permission to skip rendered GJC setup. The user-facing invocation is `/skill:deep-interview`; do not recommend or advertise `/deep-interview` or `/gajae-code:deep-interview` as the deep-interview entrypoint. Regardless of invocation path, Phase 0 below remains blocking and must resolve `gjc.deepInterview.ambiguityThreshold` from settings before any announcement, state write, question, or ambiguity score.
+If this raw bundled skill is loaded by GJC's native skill loader through `/skill:deep-interview` or `gjc deep-interview`, do not treat that path as permission to skip rendered GJC setup. The user-facing invocation is `/skill:deep-interview`; do not recommend or advertise deprecated aliases as the deep-interview entrypoint. Regardless of invocation path, Phase 0 below remains blocking and must resolve `gjc.deepInterview.ambiguityThreshold` from settings before any announcement, state write, question, or ambiguity score.
 
 ## Phase 0: Resolve Ambiguity Threshold (blocking prerequisite)
 
-Complete this phase before Phase 1, before brownfield exploration, before `state_write`, before Round 0, and before any ambiguity scoring. Do not continue if the resolved threshold and source are unknown.
+Complete this phase before Phase 1, before brownfield exploration, before GJC state persistence, before Round 0, and before any ambiguity scoring. Do not continue if the resolved threshold and source are unknown.
 
 1. **Read threshold settings in precedence order**:
    - User settings: `[$GJC_CONFIG_DIR|~/.gjc]/settings.json`
@@ -81,7 +81,7 @@ Deep Interview threshold: <resolvedThresholdPercent> (source: <resolvedThreshold
 
 4. **Carry threshold source forward mechanically**:
    - Substitute `<resolvedThreshold>`, `<resolvedThresholdPercent>`, and `<resolvedThresholdSource>` throughout the remaining instructions before continuing.
-   - Include `threshold_source` in the first `state_write(mode="deep-interview")` state payload and preserve it on later state updates.
+   - Include `threshold_source` in the first `gjc state write` payload (or `.gjc/state/` state file) and preserve it on later state updates.
    - Include both threshold and source in the final spec metadata.
 
 ## Phase 1: Initialize
@@ -106,9 +106,9 @@ Deep Interview threshold: <resolvedThresholdPercent> (source: <resolvedThreshold
    - Wait until the summary exists before ambiguity scoring, weakest-dimension selection, brownfield exploration prompts, or any bridge to `ralplan`, `execution`, `execution`, or `team`.
 3.7. **Artifact path discipline**:
    - Final specs MUST be written to `.gjc/specs/deep-interview-{slug}.md` exactly.
-   - Ephemeral interview artifacts (scoring scratchpads, prompt-safe summaries, transient queues, resume metadata) belong in `.gjc/state/` or in `state_write` state, never in the repo root or arbitrary working files.
+   - Ephemeral interview artifacts (scoring scratchpads, prompt-safe summaries, transient queues, resume metadata) belong in `.gjc/state/` or via `gjc state write` when available, never in the repo root or arbitrary working files.
 
-4. **Initialize state** via `state_write(mode="deep-interview")`:
+4. **Initialize state** via `gjc state write` when available, otherwise by writing the deep-interview state under `.gjc/state/`:
 
 ```json
 {
@@ -226,7 +226,7 @@ Build the question generation prompt with:
 - Brownfield codebase context (if applicable), summarized to cited paths/symbols/patterns instead of raw dumps
 - Locked topology from Round 0, including active components, deferred components, prior per-component scores, and `last_targeted_component_id`
 
-If any prompt input is too large, summarize it first and then continue from the summary. Do not ask the next `AskUserQuestion`, score ambiguity, or hand off to execution from an over-budget raw transcript.
+If any prompt input is too large, summarize it first and then continue from the summary. Do not ask the next the `ask` tool, score ambiguity, or hand off to execution from an over-budget raw transcript.
 
 **Question targeting strategy:**
 - Identify the active component + dimension pair with the LOWEST clarity score across the locked topology
@@ -247,7 +247,7 @@ If any prompt input is too large, summarize it first and then continue from the
 
 ### Step 2b: Ask the Question
 
-Use `AskUserQuestion` with the generated question. Present it clearly with the current ambiguity context:
+Use the `ask` tool with the generated question. Present it clearly with the current ambiguity context:
 
 ```
 Round {n} | Component: {target_component_name} | Targeting: {weakest_dimension} | Why now: {one_sentence_targeting_rationale} | Ambiguity: {score}%
@@ -354,7 +354,7 @@ Round {n} complete.
 
 ### Step 2e: Update State
 
-Update interview state with the new round, global scores, per-component `topology.components[].clarity_scores`, `topology.components[].weakest_dimension`, ontology snapshot, and `topology.last_targeted_component_id` via `state_write`.
+Update interview state with the new round, global scores, per-component `topology.components[].clarity_scores`, `topology.components[].weakest_dimension`, ontology snapshot, and `topology.last_targeted_component_id` via `gjc state write`.
 
 ### Step 2f: Check Soft Limits
 
@@ -388,7 +388,7 @@ When ambiguity ≤ threshold (or hard cap / early exit):
 1. **Generate the specification** using opus model with the prompt-safe transcript. If the full interview transcript or initial context is too large, include the summary plus all concrete decisions, acceptance criteria, unresolved gaps, and ontology snapshots; never overflow the prompt with raw oversized context.
 2. **Write to file**: `.gjc/specs/deep-interview-{slug}.md`
    - Always use this exact final spec path. Do not write temporary working files to the repo root or other ad hoc paths; repos may allowlist `.gjc/` for planning artifacts while protecting product branches.
-   - For ephemeral artifacts during interview rounds (for example scoring intermediate results, prompt-safe summaries, question queues, or resume metadata), use `.gjc/state/` or in-memory state via `state_write`.
+   - For ephemeral artifacts during interview rounds (for example scoring intermediate results, prompt-safe summaries, question queues, or resume metadata), use `.gjc/state/` or in-memory state via `gjc state write`.
    - Persist the final `spec_path` in state when available so downstream skills and resumed sessions can pass the artifact path explicitly.
 
 Spec structure:
@@ -483,9 +483,9 @@ Spec structure:
 
 ## Phase 5: Execution Bridge
 
-**Research workflow override:** if `--research-setup` is active, skip the standard execution options below. The only valid bridge is the `Skill("gajae-code:research workflow")` handoff described above. The `gjc research workflow` CLI is a hard-deprecated shim and must not be used for execution.
+**Research workflow override:** if `--research-setup` is active, skip the standard execution options below and write a pending-approval spec that names research setup as an unresolved follow-up. Do not invoke deprecated research workflow shims.
 
-After the spec is written, mark it `pending approval` and present execution options via `AskUserQuestion`. Until the user selects an execution option, the deep-interview module MUST NOT run mutation-oriented shell commands, edit source files, commit, push, open PRs, invoke execution skills, or delegate implementation tasks:
+After the spec is written, mark it `pending approval` and present execution options via the `ask` tool. Until the user selects an execution option, the deep-interview module MUST NOT run mutation-oriented shell commands, edit source files, commit, push, open PRs, invoke execution skills, or delegate implementation tasks:
 
 **Question:** "Your spec is ready (ambiguity: {score}%). How would you like to proceed?"
 
@@ -493,26 +493,26 @@ After the spec is written, mark it `pending approval` and present execution opti
 
 1. **Refine with ralplan consensus (Recommended)**
    - Description: "Consensus-refine this spec with Planner/Architect/Critic, then stop for explicit execution approval. Maximum quality."
-   - Action: Only after the user selects this option, invoke `Skill("gajae-code:plan")` with `--consensus --direct` flags and the spec file path as context. The `--direct` flag skips the ralplan skill's interview phase (the deep interview already gathered requirements), while `--consensus` triggers the Planner/Architect/Critic loop. When consensus completes and produces a plan in `.gjc/plans/`, stop with that plan marked `pending approval`; do not automatically invoke execution or any other execution skill.
+   - Action: Only after the user selects this option, invoke `/skill:ralplan` or `gjc ralplan --consensus --direct` with the spec file path as context. The `--direct` flag skips the ralplan skill's interview phase (the deep interview already gathered requirements), while `--consensus` triggers the Planner/Architect/Critic loop. When consensus completes and produces a plan in `.gjc/plans/`, stop with that plan marked `pending approval`; do not automatically invoke execution or any other execution skill.
    - Pipeline: `deep-interview spec → explicit approval to refine → ralplan --consensus --direct → pending approval → separate execution approval`
 
 2. **Execute with team**
    - Description: "Full autonomous pipeline — planning, parallel implementation, QA, validation. Faster but without consensus refinement."
-   - Action: Invoke `Skill("gajae-code:execution")` with the spec file path as context only after the user explicitly selects this execution option. The spec replaces execution's Phase 0 — execution starts at Phase 1 (Planning).
+   - Action: Invoke `/skill:team` or `gjc team` with the spec file path as context only after the user explicitly selects this execution option. The spec replaces team planning input.
 
 3. **Execute with team**
    - Description: "Persistence loop with architect verification — keeps working until all acceptance criteria pass"
-   - Action: Invoke `Skill("gajae-code:execution")` with the spec file path as the task definition.
+   - Action: Invoke `/skill:team` or `gjc team` with the spec file path as the task definition.
 
 4. **Execute with team**
    - Description: "N coordinated parallel agents — fastest execution for large specs"
-   - Action: Invoke `Skill("gajae-code:team")` with the spec file path as the shared plan.
+   - Action: Invoke `/skill:team` or `gjc team` with the spec file path as the shared plan.
 
 5. **Refine further**
    - Description: "Continue interviewing to improve clarity (current: {score}%)"
    - Action: Return to Phase 2 interview loop.
 
-**IMPORTANT:** On explicit execution selection, **MUST** invoke the chosen skill via `Skill()`. Do NOT implement directly. The deep-interview agent is a requirements agent, not an execution agent. If oversized initial context was summarized, pass the spec and prompt-safe summary forward, not the raw oversized source material. Without explicit execution selection, stop with the spec marked `pending approval`.
+**IMPORTANT:** On explicit execution selection, **MUST** use the chosen public GJC workflow entrypoint (`/skill:ralplan`, `/skill:team`, `gjc ralplan`, or `gjc team`). Do NOT implement directly. The deep-interview agent is a requirements agent, not an execution agent. If oversized initial context was summarized, pass the spec and prompt-safe summary forward, not the raw oversized source material. Without explicit execution selection, stop with the spec marked `pending approval`.
 
 ### Approval-Gated Refinement Path (Recommended)
 
@@ -541,14 +541,14 @@ Skipping any stage is possible but reduces quality assurance:
 </Steps>
 
 <Tool_Usage>
-- Use `AskUserQuestion` for each interview question — provides clickable UI with contextual options
-- Preserve the AskUserQuestion path for GJC-native interaction; do not introduce GJC-only structured-question transport into this skill
-- Use `Task(subagent_type="gajae-code:explore", model="haiku")` for brownfield codebase exploration (run BEFORE asking user about codebase)
+- Use the `ask` tool for each interview question — provides clickable UI with contextual options
+- Preserve the GJC `ask` tool path for native interaction; do not introduce parallel structured-question transport into this skill
+- Use `read/search/find exploration or a bounded read-only planner/architect subagent` for brownfield codebase exploration (run BEFORE asking user about codebase)
 - Use opus model (temperature 0.1) for ambiguity scoring — consistency is critical
 - Round 0 topology confirmation happens before ambiguity scoring; Phase 2 scoring must honor locked topology and rotate targeting across active components when more than one is present
-- Use `state_write` / `state_read` for interview state persistence; the initial and subsequent deep-interview state payloads must include `threshold_source` alongside `threshold`
-- Use `Write` tool to save the final spec to `.gjc/specs/deep-interview-{slug}.md` exactly; use `.gjc/state/` or `state_write` for ephemeral artifacts
-- Use `Skill()` to bridge to execution modes only after explicit execution approval — never implement directly
+- Use `gjc state write` / `gjc state read` for interview state persistence; the initial and subsequent deep-interview state payloads must include `threshold_source` alongside `threshold`
+- Use the `write` tool to save the final spec to `.gjc/specs/deep-interview-{slug}.md` exactly; use `.gjc/state/` or `gjc state write` for ephemeral artifacts
+- Use public GJC workflow entrypoints to bridge to ralplan/team only after explicit execution approval — never implement directly
 - Challenge agent modes are prompt injections, not separate agent spawns
 </Tool_Usage>
 
@@ -671,12 +671,12 @@ Why bad: 45% ambiguity means nearly half the requirements are unclear. The mathe
 - [ ] Ambiguity score displayed after every round
 - [ ] Every round explicitly names the weakest dimension and why it is the next target
 - [ ] Challenge agents activated at correct thresholds (round 4, 6, 8)
-- [ ] Spec file written to `.gjc/specs/deep-interview-{slug}.md` exactly; ephemeral artifacts stayed under `.gjc/state/` or `state_write`
+- [ ] Spec file written to `.gjc/specs/deep-interview-{slug}.md` exactly; ephemeral artifacts stayed under `.gjc/state/` or `gjc state write`
 - [ ] Spec includes: topology, goal, constraints, acceptance criteria, clarity breakdown, transcript
-- [ ] Execution bridge presented via AskUserQuestion
-- [ ] Selected execution mode invoked via Skill() only after explicit execution approval (never direct implementation)
+- [ ] Execution bridge presented via the `ask` tool
+- [ ] Selected execution mode invoked via public GJC workflow entrypoint only after explicit execution approval (never direct implementation)
 - [ ] If 3-stage pipeline selected: ralplan --consensus --direct invoked, then stopped with the consensus plan marked `pending approval` until the user explicitly approves execution
-- [ ] State cleaned up after execution handoff
+- [ ] State cleaned up after approved workflow handoff
 - [ ] Brownfield confirmation questions cite repo evidence (file/path/pattern) before asking the user to decide
 - [ ] Scope-fuzzy tasks can trigger ontology-style questioning to stabilize the core entity before feature elaboration
 - [ ] Round 0 topology gate completed before ambiguity scoring and persisted `topology.confirmed_at`
@@ -712,17 +712,17 @@ Optional settings in `.gjc/settings.json`:
 
 If interrupted, run `/skill:deep-interview` again. The skill reads state from `.gjc/state/deep-interview-state.json` and resumes from the last completed round.
 
-## Integration with Staged execution
+## Integration with staged team routing
 
 When team receives a vague input (no file paths, function names, or concrete anchors), it can redirect to deep-interview:
 
 ```
 User: "team build me a thing"
-Staged execution: "Your request is quite open-ended. Would you like to run a deep interview first to clarify requirements?"
+Team routing: "Your request is quite open-ended. Would you like to run a deep interview first to clarify requirements?"
   [Yes, interview first] [No, expand directly]
 ```
 
-If the user chooses interview, execution invokes `/skill:deep-interview`. When the interview completes and the user selects "Execute with team", the spec becomes Phase 0 output and execution continues from Phase 1 (Planning).
+If the user chooses interview, team routing invokes `/skill:deep-interview`. When the interview completes and the user selects "Execute with team", the spec becomes Phase 0 output and team proceeds from the approved spec.
 
 ## Approval-Gated Pipeline: deep-interview → ralplan → pending approval
 
@@ -753,7 +753,7 @@ The recommended refinement path chains clarity and feasibility gates, then stops
 
 ## Integration with Ralplan Gate
 
-The ralplan pre-execution gate already redirects vague prompts to planning. Deep interview can serve as an alternative redirect target for prompts that are too vague even for ralplan:
+The ralplan pre-approval gate already redirects vague prompts to planning. Deep interview can serve as an alternative redirect target for prompts that are too vague even for ralplan:
 
 ```
 Vague prompt → ralplan gate → deep-interview (if extremely vague) → ralplan (with clear spec) → pending approval → explicitly approved execution

package/src/defaults/gjc/skills/team/SKILL.md

@@ -155,6 +155,7 @@ Important:
 
 - Leader remains in the existing left pane.
 - Worker panes are independent full GJC worker CLI sessions on the right side of a leader-left/worker-right split.
+- Worker CLI selection is teammate-only: `GJC_TEAM_WORKER_CLI` and `GJC_TEAM_WORKER_CLI_MAP` accept only `auto` or `gjc`; legacy/provider values such as `codex`, `claude`, or `gemini` are rejected before launch.
 - The worker may run in a dedicated git worktree (`gjc team --worktree[=<name>]`) while sharing the team state root.
 - `shutdown` kills only the recorded worker pane after confirming it still belongs to the stored tmux target and is not the leader pane. It never kills the tmux session.
 

package/src/defaults/gjc/skills/ultragoal/SKILL.md

@@ -65,14 +65,14 @@ Loop until `gjc ultragoal status` reports all goals complete:
 4. If no active GJC goal exists, call `create_goal({"objective":"<printed payload objective>"})` with the printed payload. In aggregate mode, if the same aggregate objective is already active, continue the current GJC story without creating a new GJC goal.
 5. Complete the current GJC story only.
 6. Run a completion audit against the story objective and real artifacts/tests.
-7. In aggregate mode, do **not** call `update_goal` for intermediate stories; checkpoint with a fresh `get_goal({})` snapshot whose aggregate objective is still `active`. On the final story only, first run the mandatory final cleanup/review gate below; call `update_goal({"status":"complete"})` only after that gate is clean, then call `get_goal({})` again for a fresh `complete` snapshot.
-8. Checkpoint the durable ledger with that snapshot. Intermediate aggregate checkpoints use only `--gjc-goal-json`; final clean checkpoints also require `--quality-gate-json`:
-   `gjc ultragoal checkpoint --goal-id <id> --status complete --evidence "<evidence>" --gjc-goal-json <get_goal-json-or-path> [--quality-gate-json <quality-gate-json-or-path>]`
+7. Before any `--status complete` checkpoint, run the mandatory final cleanup/review gate below. In aggregate mode, do **not** call `update_goal` for intermediate stories; checkpoint with a fresh `get_goal({})` snapshot whose aggregate objective is still `active`. On the final story only, call `update_goal({"status":"complete"})` after the gate is clean, then call `get_goal({})` again for a fresh `complete` snapshot.
+8. Checkpoint the durable ledger with that snapshot. Complete checkpoints require `--quality-gate-json`; the runtime hook rejects closure without a clean architect review:
+   `gjc ultragoal checkpoint --goal-id <id> --status complete --evidence "<evidence>" --gjc-goal-json <get_goal-json-or-path> --quality-gate-json <quality-gate-json-or-path>`
 9. If blocked or failed, checkpoint failure:
    `gjc ultragoal checkpoint --goal-id <id> --status failed --evidence "<blocker/evidence>"`
-10. For legacy per-story completed-goal blockers, preserve the non-terminal blocker with:
+11. For legacy per-story completed-goal blockers, preserve the non-terminal blocker with:
    `gjc ultragoal checkpoint --goal-id <id> --status blocked --evidence "<completed legacy GJC goal blocks create_goal in this thread>" --gjc-goal-json <get_goal-json-or-path>`
-11. Resume failed goals with `gjc ultragoal complete-goals --retry-failed`.
+12. Resume failed goals with `gjc ultragoal complete-goals --retry-failed`.
 
 ## Dynamic steering
 
@@ -120,6 +120,8 @@ If an Ultragoal request has no approved plan or consensus artifact, run `ralplan
 
 The Ultragoal leader owns `.gjc/ultragoal/goals.json` and `.gjc/ultragoal/ledger.jsonl`. Role agents return implementation/review evidence; they do not checkpoint Ultragoal or mutate goal state.
 
+For large subgoals with independent slices, the Ultragoal leader must spawn parallel `executor` subagents instead of doing serial solo work. Split only cleanly separable files/surfaces, give each executor bounded targets and acceptance criteria, and keep checkpoint ownership in the leader. Use `architect` / `critic` review lanes after integration; do not let worker agents mutate `.gjc/ultragoal` or call goal tools.
+
 ## Use Ultragoal and Team together
 
 Use ultragoal and team together for a durable Ultragoal story that benefits from one visible tmux worker session. Ultragoal remains leader-owned: `.gjc/ultragoal/goals.json` stores the story plan and `.gjc/ultragoal/ledger.jsonl` stores checkpoints. Team is the single-worker tmux execution engine and returns task/evidence status to the leader.
@@ -132,9 +134,9 @@ gjc ultragoal checkpoint --goal-id <id> --status complete --evidence "<team evid
 
 Workers do not own ultragoal goal state, do not create worker ultragoal ledgers, and do not checkpoint Ultragoal. Team launch remains explicit; Ultragoal does not auto-launch Team and performs no hidden goal mutation.
 
-## Mandatory final cleanup and review gate
+## Mandatory completion cleanup and review gate
 
-The final ultragoal story is not complete until the active agent has run the final quality gate:
+An ultragoal story cannot be checkpointed `complete` until the active agent has run the quality gate:
 
 1. Run targeted verification for the story.
 2. Run a cleanup/refactor review pass on changed files only; if there are no relevant edits, the cleaner still runs and records a passed/no-op report.
@@ -142,28 +144,56 @@ The final ultragoal story is not complete until the active agent has run the fin
 4. Run a final code review pass. Clean means `codeReview.recommendation: "APPROVE"` and `codeReview.architectStatus: "CLEAR"`; `COMMENT`, `WATCH`, `REQUEST CHANGES`, and `BLOCK` are non-clean.
 5. If review is non-clean, do **not** call `update_goal`. Record durable blocker work instead:
 
+1. Run targeted implementation verification for the story.
+2. Delegate an `architect` review covering all three lanes:
+   - architecture-side: system boundaries, layering, data/control flow, operational risks.
+   - product-side: user-visible behavior, acceptance criteria, edge cases, regressions.
+   - code-side: maintainability, tests, integration points, and unsafe shortcuts.
+3. Delegate an `executor` QA/red-team lane to build and run the e2e/read-teaming QA suite appropriate for the story. This lane must try to break the change, not just confirm the happy path.
+4. If any lane finds an issue, do **not** checkpoint `complete` and do **not** call `update_goal`. Record durable blocker work instead:
    ```sh
-   gjc ultragoal record-review-blockers --goal-id <id> --title "Resolve final review blockers" --objective "<blocker-resolution objective>" --evidence "<review findings>" --gjc-goal-json <active-get-goal-json-or-path>
+   gjc ultragoal record-review-blockers --goal-id <id> --title "Resolve verification blockers" --objective "<blocker-resolution objective>" --evidence "<architect/executor findings>" --gjc-goal-json <active-get-goal-json-or-path>
    ```
+5. Complete or steer through the blocker story, then rerun the full blocking verification loop. Repeat until all verifier lanes are clean.
+6. Only after the loop is clean, checkpoint the story as complete with a structured quality gate. The checkpoint creates a receipt; `goals.json.status` alone is not proof. Aggregate direct completion requires a fresh final aggregate receipt covering the full required-goal set before `update_goal({"status":"complete"})` is allowed.
 
-   This marks the current story `review_blocked`, appends a pending blocker-resolution story, keeps the GJC goal active, and lets `gjc ultragoal complete-goals` start the blocker next. In legacy per-story mode, the blocker may need an available GJC goal context because the old per-story GJC goal remains active/incomplete.
-
-6. If review is clean, call `update_goal({"status":"complete"})`, call `get_goal({})`, and checkpoint with a structured final gate:
-
-   ```sh
-   gjc ultragoal checkpoint --goal-id <id> --status complete --evidence "<tests/files/review evidence>" --gjc-goal-json <fresh-complete-get-goal-json-or-path> --quality-gate-json <quality-gate-json-or-path>
-   ```
-
-`--quality-gate-json` must include:
+The native `checkpoint --status complete` command rejects missing or shallow gates. `--quality-gate-json` must include:
 
 ```json
 {
-  "aiSlopCleaner": { "status": "passed", "evidence": "cleaner report" },
-  "verification": { "status": "passed", "commands": ["npm test"], "evidence": "post-cleaner verification" },
-  "codeReview": { "recommendation": "APPROVE", "architectStatus": "CLEAR", "evidence": "final review synthesis" }
+  "architectReview": {
+    "architectureStatus": "CLEAR",
+    "productStatus": "CLEAR",
+    "codeStatus": "CLEAR",
+    "recommendation": "APPROVE",
+    "evidence": "architect review synthesis with architecture/product/code coverage",
+    "commands": ["architect review command or agent evidence id"],
+    "blockers": []
+  },
+  "executorQa": {
+    "status": "passed",
+    "e2eStatus": "passed",
+    "redTeamStatus": "passed",
+    "evidence": "executor-built e2e and red-team QA commands/results",
+    "e2eCommands": ["bun test:e2e"],
+    "redTeamCommands": ["bun test:red-team"],
+    "blockers": []
+  },
+  "iteration": {
+    "status": "passed",
+    "evidence": "blockers were absent or resolved and the full verification loop was rerun cleanly",
+    "fullRerun": true,
+    "rerunCommands": ["bun test:e2e", "bun test:red-team"],
+    "blockers": []
+  }
 }
 ```
 
+Receipts are freshness-scoped:
+- Per-goal receipts remain fresh for their target goal unless that goal, its blocker metadata, or its supersession metadata changes.
+- Normal later `goal_started` or clean receipt-backed `goal_checkpointed` events for other goals do not stale older per-goal receipts.
+- Appending required goals or changing final required-goal state stales final aggregate receipts. Final aggregate completion requires a fresh final aggregate receipt proving no incomplete, blocked, or `review_blocked` required goals remain.
+
 ## Constraints
 
 - The shell command cannot directly invoke interactive `/goal`; it emits a model-facing handoff for the active GJC agent.
@@ -171,6 +201,6 @@ The final ultragoal story is not complete until the active agent has run the fin
 - After a completed aggregate ultragoal run, clear the goal manually with `/goal clear` before starting another ultragoal run in the same session/thread.
 - Never call `create_goal` when `get_goal` reports a different active goal.
 - Never call `update_goal` unless the aggregate run or legacy per-story goal is actually complete.
-- In aggregate mode, intermediate story checkpoints require a matching `active` GJC goal snapshot; final story completion requires a matching `complete` snapshot after `update_goal`.
+- In aggregate mode, intermediate story checkpoints require a matching `active` GJC goal snapshot; final story checkpoint also uses the active snapshot and creates the final aggregate receipt. Only after that receipt exists may `update_goal({"status":"complete"})` reconcile the inline goal state.
 - Completion checkpoints require read-only goal snapshot reconciliation: pass fresh `get_goal` JSON/path with `--gjc-goal-json`; shell commands and hooks must not mutate goal state.
 - Treat `ledger.jsonl` as the durable audit trail; checkpoint after every success or failure.

package/src/gjc-runtime/team-runtime.ts

@@ -8,6 +8,11 @@ export type GjcWorkerStatusState = "idle" | "working" | "blocked" | "done" | "fa
 
 export const GJC_TEAM_DEFAULT_WORKERS = 3;
 export const GJC_TEAM_MAX_WORKERS = 20;
+const GJC_TEAM_WORKER_CLI_ENV = "GJC_TEAM_WORKER_CLI";
+const GJC_TEAM_WORKER_CLI_MAP_ENV = "GJC_TEAM_WORKER_CLI_MAP";
+
+export type GjcTeamWorkerCli = "gjc";
+type GjcTeamWorkerCliMode = "auto" | GjcTeamWorkerCli;
 
 export interface GjcTeamLeader {
 	session_id: string;
@@ -75,6 +80,7 @@ export interface GjcTeamConfig {
 	max_workers: number;
 	state_root: string;
 	worker_command: string;
+	worker_cli_plan: GjcTeamWorkerCli[];
 	tmux_command: string;
 	tmux_session: string;
 	tmux_session_name: string;
@@ -159,6 +165,70 @@ export interface GjcTeamMailboxMessage {
 interface FsError {
 	code?: string;
 }
+
+function normalizeGjcTeamWorkerCliMode(
+	raw: string | undefined,
+	sourceEnv = GJC_TEAM_WORKER_CLI_ENV,
+): GjcTeamWorkerCliMode {
+	const normalized = String(raw ?? "auto")
+		.trim()
+		.toLowerCase();
+	if (normalized === "" || normalized === "auto") return "auto";
+	if (normalized === "gjc") return "gjc";
+	if (normalized === "codex" || normalized === "claude" || normalized === "gemini") {
+		throw new Error(`Unsupported ${sourceEnv} value "${raw}". GJC team launches GJC teammate sessions only.`);
+	}
+	throw new Error(`Invalid ${sourceEnv} value "${raw}". Expected: auto or gjc`);
+}
+
+export function resolveGjcTeamWorkerCli(env: NodeJS.ProcessEnv = process.env): GjcTeamWorkerCli {
+	const mode = normalizeGjcTeamWorkerCliMode(env[GJC_TEAM_WORKER_CLI_ENV]);
+	return mode === "auto" ? "gjc" : mode;
+}
+
+export function resolveGjcTeamWorkerCliPlan(
+	workerCount: number,
+	env: NodeJS.ProcessEnv = process.env,
+): GjcTeamWorkerCli[] {
+	if (!Number.isInteger(workerCount) || workerCount < 1) {
+		throw new Error(`workerCount must be >= 1 (got ${workerCount})`);
+	}
+	normalizeGjcTeamWorkerCliMode(env[GJC_TEAM_WORKER_CLI_ENV]);
+	const rawMap = String(env[GJC_TEAM_WORKER_CLI_MAP_ENV] ?? "").trim();
+	if (rawMap === "") {
+		const cli = resolveGjcTeamWorkerCli(env);
+		return Array.from({ length: workerCount }, () => cli);
+	}
+	const entries = rawMap.split(",").map(entry => entry.trim());
+	if (entries.length === 0 || entries.every(entry => entry.length === 0)) {
+		throw new Error(
+			`Invalid ${GJC_TEAM_WORKER_CLI_MAP_ENV} value "${env[GJC_TEAM_WORKER_CLI_MAP_ENV]}". Expected: auto or gjc`,
+		);
+	}
+	if (entries.some(entry => entry.length === 0)) {
+		throw new Error(
+			`Invalid ${GJC_TEAM_WORKER_CLI_MAP_ENV} value "${env[GJC_TEAM_WORKER_CLI_MAP_ENV]}". Empty entries are not allowed.`,
+		);
+	}
+	if (entries.length !== 1 && entries.length !== workerCount) {
+		throw new Error(
+			`Invalid ${GJC_TEAM_WORKER_CLI_MAP_ENV} length ${entries.length}; expected 1 or ${workerCount} comma-separated values.`,
+		);
+	}
+	const expanded = entries.length === 1 ? Array.from({ length: workerCount }, () => entries[0] ?? "") : entries;
+	return expanded.map(entry => {
+		const mode = normalizeGjcTeamWorkerCliMode(entry, GJC_TEAM_WORKER_CLI_MAP_ENV);
+		return mode === "auto" ? "gjc" : mode;
+	});
+}
+
+export function translateGjcWorkerLaunchArgsForCli(workerCli: GjcTeamWorkerCli, args: string[]): string[] {
+	if (workerCli !== "gjc") {
+		throw new Error(`Unsupported team worker CLI "${workerCli}". GJC team launches GJC teammate sessions only.`);
+	}
+	return [...args];
+}
+
 interface GjcTmuxLeaderContext {
 	sessionName: string;
 	windowIndex: string;
@@ -341,6 +411,7 @@ async function readConfig(dir: string): Promise<GjcTeamConfig> {
 		tmux_target: config.tmux_target ?? config.tmux_session ?? tmuxSessionName,
 		leader_cwd: config.leader_cwd ?? config.leader.cwd,
 		team_state_root: config.team_state_root ?? config.state_root,
+		worker_cli_plan: config.worker_cli_plan ?? Array.from({ length: config.worker_count }, () => "gjc"),
 	};
 }
 async function readPhase(dir: string): Promise<GjcTeamPhase> {
@@ -1227,6 +1298,7 @@ export async function startGjcTeam(options: GjcTeamStartOptions): Promise<GjcTea
 	const env = options.env ?? process.env;
 	if (!Number.isInteger(options.workerCount) || options.workerCount < 1 || options.workerCount > GJC_TEAM_MAX_WORKERS)
 		throw new Error(`invalid_team_worker_count:${options.workerCount}:expected_1_${GJC_TEAM_MAX_WORKERS}`);
+	const workerCliPlan = resolveGjcTeamWorkerCliPlan(options.workerCount, env);
 	const stateRoot = resolveGjcTeamStateRoot(cwd, env);
 	const teamName = sanitizeName(options.teamName ?? makeTeamName(options.task, env));
 	const displayName = sanitizeName(options.teamName ?? options.task).slice(0, 30) || teamName;
@@ -1256,6 +1328,7 @@ export async function startGjcTeam(options: GjcTeamStartOptions): Promise<GjcTea
 		max_workers: GJC_TEAM_MAX_WORKERS,
 		state_root: stateRoot,
 		worker_command: resolveGjcWorkerCommand(cwd, env),
+		worker_cli_plan: workerCliPlan,
 		tmux_command: tmuxCommand,
 		tmux_session: tmuxContext.sessionName,
 		tmux_session_name: tmuxContext.sessionName,
@@ -1279,6 +1352,7 @@ export async function startGjcTeam(options: GjcTeamStartOptions): Promise<GjcTea
 		tmux_session_name: config.tmux_session_name,
 		tmux_target: config.tmux_target,
 		worker_command: config.worker_command,
+		worker_cli_plan: config.worker_cli_plan,
 		tmux_command: config.tmux_command,
 		leader: config.leader,
 		workers: config.workers,
@@ -1296,7 +1370,12 @@ export async function startGjcTeam(options: GjcTeamStartOptions): Promise<GjcTea
 	await appendTelemetry(dir, {
 		type: "team_runtime",
 		message: "Native gjc team runtime initialized",
-		data: { state_root: stateRoot, worker_command: config.worker_command, workspace_mode: config.workspace_mode },
+		data: {
+			state_root: stateRoot,
+			worker_command: config.worker_command,
+			worker_cli_plan: workerCliPlan,
+			workspace_mode: config.workspace_mode,
+		},
 	});
 	let tmuxWorkers: GjcTeamWorker[];
 	try {