@gajae-code/coding-agent 0.4.0 → 0.4.2

package/src/config/settings-schema.ts

@@ -9,7 +9,6 @@ import {
 } from "./skill-settings-defaults";
 
 /** Unified settings schema - single source of truth for all settings.
- * Unified settings schema - single source of truth for all settings.
  *
  * Each setting is defined once here with:
  * - Type and default value
@@ -1010,6 +1009,16 @@ export const SETTINGS_SCHEMA = {
 		},
 	},
 
+	"starReminder.enabled": {
+		type: "boolean",
+		default: true,
+		ui: {
+			tab: "interaction",
+			label: "GitHub Star Reminder",
+			description: "Show the interactive GitHub star reminder when gh is authenticated",
+		},
+	},
+
 	collapseChangelog: {
 		type: "boolean",
 		default: false,
@@ -1089,11 +1098,12 @@ export const SETTINGS_SCHEMA = {
 	// Context promotion
 	"contextPromotion.enabled": {
 		type: "boolean",
-		default: true,
+		default: false,
 		ui: {
 			tab: "context",
 			label: "Auto-Promote Context",
-			description: "Promote to a larger-context model on context overflow instead of compacting",
+			description:
+				"Promote to a larger-context model on context overflow instead of compacting (off by default; opt in to enable)",
 		},
 	},
 

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

@@ -530,28 +530,24 @@ After the spec is written, mark it `pending approval` and present execution opti
 
 **Options:**
 
-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: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`
+1. **Refine with ralplan consensus (Recommended — default for almost all specs)**
+   - Description: "Consensus-refine this spec with Planner/Architect/Critic, then stop for explicit execution approval. Maximum quality. Prefer this unless the spec is already implementation-ready and trivially simple."
+   - Action: Only after the user selects this option, invoke `/skill:ralplan` with the spec file path as context. Ralplan is already the Planner → Architect → Critic consensus workflow, so no extra slash-skill flags are required or supported. 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 → 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:team` with the spec file path as context only after the user explicitly selects this execution option. The spec replaces team planning input.
+2. **Execute with ultragoal (only when spec is already implementation-ready and really simple)**
+   - Description: "Goal-tracked autonomous execution — drives the spec to completion with verification. Skip ralplan refinement only when the spec is concrete, low-risk, and trivially small."
+   - Action: Invoke `/skill:ultragoal` with the spec file path as context only after the user explicitly selects this execution option. The spec replaces ultragoal planning input. Recommend this only when the spec needs no further planning; otherwise route through ralplan refinement first.
 
-3. **Execute with team**
-   - Description: "Persistence loop with architect verification — keeps working until all acceptance criteria pass"
-   - Action: Invoke `/skill:team` with the spec file path as the task definition.
+3. **Execute with team (only when implementation-ready, simple, AND tmux parallelization is required)**
+   - Description: "N coordinated parallel agents in tmux — only when the spec is already implementation-ready and genuinely needs tmux-based interactive worker parallelization."
+   - Action: Invoke `/skill:team` with the spec file path as the shared plan only after the user explicitly selects this option. Reserve this for the narrow case where the spec is simple/ready and tmux interactive parallel workers are actually needed; otherwise prefer ralplan refinement, then ultragoal.
 
-4. **Execute with team**
-   - Description: "N coordinated parallel agents — fastest execution for large specs"
-   - Action: Invoke `/skill:team` with the spec file path as the shared plan.
-
-5. **Refine further**
+4. **Refine further**
    - Description: "Continue interviewing to improve clarity (current: {score}%)"
    - Action: Return to Phase 2 interview loop.
 
-**IMPORTANT:** On explicit execution selection, **MUST** use the chosen bundled GJC workflow skill entrypoint (`/skill:ralplan` or `/skill:team`) inside the agent session. `gjc ralplan` is a native CLI that accepts the documented skill flags and seeds local `.gjc/state` receipts; agent sessions should still drive the consensus loop through `/skill:ralplan`. `gjc team` is a native tmux runtime command and may be used only when the Team workflow explicitly requires the CLI runtime. 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 bundled GJC workflow skill entrypoint (`/skill:ralplan`, `/skill:ultragoal`, or `/skill:team`) inside the agent session. `gjc ralplan` is a native CLI that accepts the documented skill flags and seeds local `.gjc/state` receipts; agent sessions should still drive the consensus loop through `/skill:ralplan`. Implementation handoff defaults to `/skill:ultragoal`; `/skill:team` is reserved for when tmux-based interactive worker parallelization is genuinely required, and `gjc team` is a native tmux runtime command used only when the Team workflow explicitly requires the CLI runtime. 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`.
 
 ### Phase 5b: Handoff before chain
 
@@ -577,7 +573,7 @@ Stage 1: Deep Interview          Stage 2: ralplan consensus       Stage 3: Separ
 ┌─────────────────────┐    ┌───────────────────────────┐    ┌──────────────────────┐
 │ Socratic Q&A        │    │ Planner creates plan      │    │ User chooses if/how  │
 │ Ambiguity scoring   │───>│ Architect reviews         │───>│ execution proceeds   │
-│ Challenge agents    │    │ Critic validates          │    │ via team or ultragoal  │
+│ Challenge agents    │    │ Critic validates          │    │ via ultragoal (default) │
 │ Spec crystallization│    │ Loop until consensus      │    │ no auto-handoff      │
 │ Gate: ≤<resolvedThresholdPercent> ambiguity│    │ ADR + RALPLAN-DR summary  │    │                      │
 └─────────────────────┘    └───────────────────────────┘    └──────────────────────┘
@@ -604,7 +600,7 @@ Skipping any stage is possible but reduces quality assurance:
 - 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 `gjc state write` / `gjc state read` for interview state persistence; the initial and subsequent deep-interview state payloads must include `threshold_source` alongside `threshold`; do not edit `.gjc/state` directly without force override.
 - Use the GJC workflow CLI to save the final spec at `.gjc/specs/deep-interview-{slug}.md` exactly; do not use `write`, `edit`, or `ast_edit` directly on `.gjc/` paths without force override.
-- Use public GJC workflow entrypoints to bridge to ralplan/team only after explicit execution approval — never implement directly
+- Use public GJC workflow entrypoints to bridge to ralplan, ultragoal, or team only after explicit execution approval — never implement directly. Implementation handoff defaults to ultragoal; reserve team for when tmux-based interactive worker parallelization is genuinely required.
 - Challenge agent modes are prompt injections, not separate agent spawns
 - Use internal fragment auto-modes only at their documented hooks: `auto-research-greenfield.md` between Step 2a and 2b for greenfield `research: true` questions, and `auto-answer-uncertain.md` as Step 2b′ after `ask` resolves and before scoring.
 - Fragment auto-modes are loaded on demand as `kind: "skill-fragment"`; they are not public workflow skills, not slash-command/discoverable, and not `skill://` registrations.
@@ -734,7 +730,7 @@ Why bad: 45% ambiguity means nearly half the requirements are unclear. The mathe
 - [ ] Spec includes: topology, goal, constraints, acceptance criteria, clarity breakdown, transcript
 - [ ] 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
+- [ ] If 3-stage pipeline selected: `/skill:ralplan` invoked with the spec as context, then stopped with the consensus plan marked `pending approval` until the user explicitly approves execution
 - [ ] 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
@@ -783,7 +779,7 @@ Team routing: "Your request is quite open-ended. Would you like to run a deep in
   [Yes, interview first] [No, expand directly]
 ```
 
-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.
+If the user chooses interview, team routing invokes `/skill:deep-interview`. When the interview completes and the user selects an execution path (ultragoal by default, or team when tmux-based interactive parallelization is required), the spec becomes Phase 0 output and the chosen workflow proceeds from the approved spec.
 
 ## Approval-Gated Pipeline: deep-interview → ralplan → pending approval
 
@@ -794,17 +790,17 @@ The recommended refinement path chains clarity and feasibility gates, then stops
   → Socratic Q&A until ambiguity ≤ <resolvedThresholdPercent>
   → Spec written to .gjc/specs/deep-interview-{slug}.md
   → User explicitly selects "Refine with ralplan consensus"
-  → /skill:ralplan --consensus --direct (spec as input, skip interview)
+  → /skill:ralplan (spec as input)
     → Planner creates implementation plan from spec
     → Architect reviews for architectural soundness
     → Critic validates quality and testability
     → Loop until consensus (max 5 iterations)
     → Consensus plan written to .gjc/plans/
   → Stop with the consensus plan marked pending approval
-  → Only a separate explicit execution approval may invoke team or ultragoal
+  → Only a separate explicit execution approval may invoke execution (ultragoal by default; team only when tmux-based interactive worker parallelization is required)
 ```
 
-**The ralplan skill receives the spec with `--consensus --direct` flags** because the deep interview already did the requirements gathering. The `--direct` flag (supported by the ralplan skill, which ralplan aliases) skips the interview phase and goes straight to Planner → Architect → Critic consensus. The consensus plan includes:
+**The ralplan skill receives the spec as context through `/skill:ralplan`** because ralplan is already the GJC Planner → Architect → Critic consensus workflow. The consensus plan includes:
 - RALPLAN-DR summary (Principles, Decision Drivers, Options)
 - ADR (Decision, Drivers, Alternatives, Why chosen, Consequences)
 - Testable acceptance criteria (inherited from deep-interview spec)

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

@@ -61,7 +61,7 @@ The consensus workflow:
    - Viable Options (>=2) with bounded pros/cons
    - If only one viable option remains, explicit invalidation rationale for alternatives
    - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability)
-2. **User feedback** *(--interactive only)*: If `--interactive` is set, use `AskUserQuestion` to present the draft plan **plus the Principles / Drivers / Options summary** before review (Proceed to review / Request changes / Skip review). Otherwise, automatically proceed to review.
+2. **User feedback** *(--interactive only)*: If `--interactive` is set, use the `ask` tool to present the draft plan **plus the Principles / Drivers / Options summary** before review (Proceed to review / Request changes / Skip review). Otherwise, automatically proceed to review.
 3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — **await completion before step 4**. In deliberate mode, Architect should explicitly flag principle violations.
    - The Architect agent/subagent must persist its review with `gjc ralplan --write --stage architect --stage_n <N> --artifact "..." --json`, then return the receipt/path plus compact verdict/status (`CLEAR`/`WATCH`/`BLOCK`, `APPROVE`/`COMMENT`/`REQUEST CHANGES`) instead of pasting the full review body.
 4. **Critic** evaluates against quality criteria — run only after step 3 completes. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing/weak pre-mortem or expanded test plan.
@@ -74,9 +74,9 @@ The consensus workflow:
    d. Return to Critic evaluation
    e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached
    f. If 5 iterations are reached without `APPROVE`, present the best version to the user
-6. On Critic approval, mark the plan `pending approval` unless explicit execution approval has already been captured, persist the ADR/final plan via `gjc ralplan --write --stage final --stage_n <N> --artifact "..."`, and do not directly edit `.gjc/plans`. *(--interactive only)* If `--interactive` is set, use `AskUserQuestion` to present the plan with approval options (Approve execution via team (Recommended) / Compact then return for execution approval / Request changes / Reject). Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups). Otherwise, output the final plan and stop before any mutation or delegation.
-7. *(--interactive only)* User chooses: Approve team execution, Request changes, or Reject
-8. *(--interactive only)* On approval: invoke `/skill:team` for execution -- never implement directly
+6. On Critic approval, mark the plan `pending approval` unless explicit execution approval has already been captured, persist the ADR/final plan via `gjc ralplan --write --stage final --stage_n <N> --artifact "..."`, and do not directly edit `.gjc/plans`. *(--interactive only)* If `--interactive` is set, use the `ask` tool to present the plan with approval options (Approve execution via ultragoal (Recommended) / Approve execution via team (only when tmux-based interactive worker parallelization is required) / Compact then return for execution approval / Request changes / Reject). Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups). Otherwise, output the final plan and stop before any mutation or delegation.
+7. *(--interactive only)* User chooses: Approve ultragoal execution (recommended), Approve team execution (tmux parallelization only), Request changes, or Reject
+8. *(--interactive only)* On approval: invoke `/skill:ultragoal` for execution by default; invoke `/skill:team` only when the user explicitly needs tmux-based interactive worker parallelization -- never implement directly
 
    Before invoking `/skill:team` or `/skill:ultragoal`, mark ralplan ready for handoff so the skill tool's chain guard permits the transition:
 
@@ -121,7 +121,7 @@ Set `--planner-resumable true` only when the parent session is provably persiste
 
 ### Why the Gate Exists
 
-Execution modes (team, team, team, team, team) spin up heavy multi-agent orchestration. When launched on a vague request like "team improve the app", agents have no clear target — they waste cycles on scope discovery that should happen during planning, often delivering partial or misaligned work that requires rework.
+Execution skills (`ultragoal` and `team`) drive implementation rather than scope discovery. When launched on a vague request like "team improve the app", agents have no clear target — they waste cycles on scope discovery that should happen during planning, often delivering partial or misaligned work that requires rework.
 
 The ralplan-first gate intercepts underspecified execution requests and redirects them through the ralplan consensus planning workflow. This ensures:
 - **Explicit scope**: A PRD defines exactly what will be built
@@ -177,8 +177,8 @@ The gate auto-passes when it detects **any** concrete signal. You do not need al
    - **Architect** reviews for soundness
    - **Critic** validates quality and testability
 5. On consensus approval, user chooses execution path:
-   - **team**: parallel coordinated agents (recommended)
-   - **team**: sequential execution with verification
+   - **ultragoal**: goal-tracked autonomous execution with verification (recommended default)
+   - **team**: N coordinated parallel agents in tmux — only when tmux-based interactive worker parallelization is required
 6. Execution begins with a clear, bounded plan
 
 ### Troubleshooting

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

@@ -124,6 +124,15 @@ When `$team` is used as a follow-up mode from ralplan, carry forward the approve
 - explain why each lane exists (delivery, verification, specialist support)
 - include an explicit launch hint (`gjc team "<task>"` / `$team "<task>"`) for the coordinated worker run; mention `$ultragoal` as the default durable follow-up/ledger path; mention a later separate Single-owner execution follow-up only when explicitly requested or genuinely needed as a fallback
 - if the ideal role is unavailable, choose the closest role from the roster and say so
+- For multi-worker follow-up execution, do not pass an inline "Split lanes: A..., B..." sentence as the whole team task. `gjc team` rejects ambiguous inline lane splits because they previously caused every worker to receive the same broad task. Use explicit markdown lane sections instead:
+  ```md
+  ### Lane A — Delivery
+  Implement delivery-only changes and evidence.
+
+  ### Lane B — Verification
+  Add focused tests and smoke evidence.
+  ```
+  Explicit `### Lane <id> — <title>` sections are converted into distinct worker-owned initial tasks.
 
 ## Current Runtime Behavior (As Implemented)
 
@@ -134,7 +143,7 @@ When `$team` is used as a follow-up mode from ralplan, carry forward the approve
 3. Initialize team state:
    - `.gjc/state/team/<team>/config.json`
    - `.gjc/state/team/<team>/manifest.v2.json`
-   - `.gjc/state/team/<team>/tasks/task-1.json`
+   - `.gjc/state/team/<team>/tasks/task-*.json` (one per explicit lane section, otherwise one worker-owned compatibility task per worker)
    - `.gjc/state/team/<team>/mailbox/worker-1.json`
    - `.gjc/state/team/<team>/workers/<worker>/status.json`
    - `.gjc/state/team/<team>/workers/<worker>/lifecycle.json`

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

@@ -96,11 +96,12 @@ Loop until `gjc ultragoal status` reports all goals complete:
 7. Before any `--status complete` checkpoint, run the mandatory final cleanup/review gate below. In aggregate mode, do **not** call `goal({"op":"complete"})` for intermediate stories; checkpoint each story with a fresh `goal({"op":"get"})` snapshot whose aggregate objective is still `active`. On the final story, use the same fresh active snapshot to create the final aggregate receipt first; only after that receipt exists may `goal({"op":"complete"})` run.
 8. Checkpoint the durable ledger with that fresh active 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 <goal-get-json-or-path> --quality-gate-json <quality-gate-json-or-path>`
+   A successful complete checkpoint is story completion, not automatic run completion. Read the checkpoint output: when it prints `Next ultragoal goal: <id>`, continue that active story under the same aggregate GJC goal; when it prints `All ultragoal goals are complete`, the durable run is terminal. `gjc ultragoal complete-goals` remains the supported manual next-story command if continuation output was missed.
 9. If blocked or failed, checkpoint failure:
    `gjc ultragoal checkpoint --goal-id <id> --status failed --evidence "<blocker/evidence>"`
-11. For legacy per-story completed-goal blockers, preserve the non-terminal blocker with:
+10. 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 goal create in this thread>" --gjc-goal-json <goal-get-json-or-path>`
-12. Resume failed goals with `gjc ultragoal complete-goals --retry-failed`.
+11. Resume failed goals with `gjc ultragoal complete-goals --retry-failed`.
 
 ## Dynamic steering
 

package/src/gjc-runtime/launch-tmux.ts

@@ -48,6 +48,7 @@ export interface TmuxLaunchContext {
 	currentBranch?: string | null;
 	existingBranchSessionName?: string | null;
 	project?: string | null;
+	diagnosticWriter?: (message: string) => void;
 }
 
 export interface TmuxSpawnResult {
@@ -120,6 +121,16 @@ function isInteractiveRootLaunch(parsed: Args, tty: TtyState): boolean {
 	);
 }
 
+function isBunVirtualPath(value: string | undefined): boolean {
+	return value?.startsWith("/$bunfs/") === true;
+}
+
+function formatTmuxLaunchDiagnostic(stage: string, stderr?: string): string {
+	const detail = stderr?.trim();
+	const suffix = detail ? ` ${detail.slice(0, 240)}` : "";
+	return `gjc --tmux failed after creating tmux session: ${stage}.${suffix}\n`;
+}
+
 function shellQuote(value: string): string {
 	if (value.length === 0) return "''";
 	return `'${value.replace(/'/g, `'\\''`)}'`;
@@ -148,6 +159,9 @@ export function applyGjcTmuxProfile(context: GjcTmuxProfileContext): GjcTmuxProf
 function resolveCurrentGjcCommand(context: CommandResolutionContext): string[] {
 	const entrypoint = context.argv[1];
 	if (!entrypoint) return ["gjc"];
+	if (isBunVirtualPath(entrypoint)) {
+		return isBunVirtualPath(context.execPath) ? ["gjc"] : [context.execPath];
+	}
 	const resolvedEntrypoint = path.isAbsolute(entrypoint) ? entrypoint : path.resolve(context.cwd, entrypoint);
 	if (entrypoint.endsWith(".ts") || entrypoint.endsWith(".js") || entrypoint.endsWith(".mjs")) {
 		return [context.execPath, resolvedEntrypoint];
@@ -264,10 +278,19 @@ export function launchDefaultTmuxIfNeeded(context: TmuxLaunchContext): boolean {
 		});
 		if (profile.failures.length > 0) {
 			cleanupCreatedTmuxSession(plan, spawnSync, options);
-			return false;
+			const failure =
+				profile.failures.find(item => item.command.args.includes("@gjc-profile")) ?? profile.failures[0];
+			(context.diagnosticWriter ?? process.stderr.write.bind(process.stderr))(
+				formatTmuxLaunchDiagnostic("profile tagging failed", failure?.stderr),
+			);
+			return true;
 		}
 	}
 	if (created.exitCode !== 0) return false;
 	const attached = spawnSync(plan.tmuxCommand, ["attach-session", "-t", plan.sessionName], options);
-	return attached.exitCode === 0;
+	if (attached.exitCode === 0) return true;
+	(context.diagnosticWriter ?? process.stderr.write.bind(process.stderr))(
+		formatTmuxLaunchDiagnostic("attach failed", attached.stderr),
+	);
+	return true;
 }

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

@@ -1673,9 +1673,10 @@ function buildWorkerCommand(config: GjcTeamConfig, worker: GjcTeamWorker): strin
 		`You are ${worker.id} in gjc team ${config.team_name}.`,
 		`Team state root: ${config.state_root}.`,
 		workspace,
-		`Task: ${config.task}`,
+		`Team brief (context only): ${config.task}`,
+		"Before implementation, claim your worker-owned task and treat the claimed task record as the source of truth. Do not implement directly from the broad team brief.",
 		`Before claiming work, send startup ACK: gjc team api worker-startup-ack --input '{"team_name":"${config.team_name}","worker_id":"${worker.id}","protocol_version":"1"}' --json.`,
-		`Use gjc team api update-worker-status to report task-local activity, then claim-task/transition-task-status with this worker id; record completion_evidence (summary plus a passed command or verified inspection/artifact item) before completed, and do not mutate leader-owned goal state.`,
+		`Use gjc team api update-worker-status to report task-local activity, then claim-task/transition-task-status with this worker id; keep heartbeat current during long work, record completion_evidence (summary plus a passed command or verified inspection/artifact item) before completed, and do not mutate leader-owned goal state.`,
 	].join("\n");
 	const env = [
 		`GJC_TEAM_WORKER=${shellQuote(`${config.team_name}/${worker.id}`)}`,
@@ -1689,7 +1690,80 @@ function buildWorkerCommand(config: GjcTeamConfig, worker: GjcTeamWorker): strin
 	];
 	return `${env.join(" ")} ${config.worker_command} ${shellQuote(prompt)}`;
 }
+interface GjcTeamInitialLane {
+	label: string;
+	title: string;
+	body: string;
+}
+
+function normalizeLaneId(label: string): string {
+	return `lane-${sanitizeName(label).toLowerCase() || stableHash(label).slice(0, 8)}`;
+}
+
+function parseExplicitTeamLanes(task: string): GjcTeamInitialLane[] {
+	const lines = task.split(/\r?\n/);
+	const lanes: GjcTeamInitialLane[] = [];
+	let current: { label: string; title: string; body: string[] } | null = null;
+	const laneHeading = /^#{2,6}\s+Lane\s+([A-Za-z0-9]+)\s*(?:[—–-]\s*(.+))?\s*$/;
+	const boundaryHeading = /^#{1,6}\s+(?:Integration Owner|Verification Plan|ADR|Approval State)\b/i;
+
+	for (const line of lines) {
+		const match = line.match(laneHeading);
+		if (match) {
+			if (current) lanes.push({ ...current, body: current.body.join("\n").trim() });
+			current = {
+				label: match[1] ?? `${lanes.length + 1}`,
+				title: (match[2] ?? `Lane ${match[1] ?? lanes.length + 1}`).trim(),
+				body: [],
+			};
+			continue;
+		}
+		if (current && boundaryHeading.test(line)) {
+			lanes.push({ ...current, body: current.body.join("\n").trim() });
+			current = null;
+			continue;
+		}
+		if (current) current.body.push(line);
+	}
+	if (current) lanes.push({ ...current, body: current.body.join("\n").trim() });
+	return lanes.filter(lane => lane.body.length > 0 || lane.title.length > 0);
+}
+
+function hasAmbiguousLaneSplitIntent(task: string): boolean {
+	return (
+		/\bsplit\s+lanes?\s*:/i.test(task) || /\blanes?\s*:\s*[A-Z]\b/i.test(task) || /\bLane\s+[A-Z]\s*[—–-]/.test(task)
+	);
+}
+
 function buildInitialTasks(task: string, workers: GjcTeamWorker[]): GjcTeamTask[] {
+	const lanes = parseExplicitTeamLanes(task);
+	if (lanes.length > 0)
+		return lanes.map((lane, index) => {
+			const worker = workers[index % workers.length];
+			if (!worker) throw new Error("team_lane_requires_worker");
+			const laneTitle = `Lane ${lane.label} — ${lane.title}`;
+			const objective = [`${laneTitle}`, lane.body].filter(part => part.trim().length > 0).join("\n\n");
+			return {
+				id: `task-${index + 1}`,
+				subject: laneTitle,
+				description: objective,
+				title: laneTitle,
+				objective,
+				status: "pending",
+				owner: worker.id,
+				lane: normalizeLaneId(lane.label),
+				required_role: worker.role,
+				version: 1,
+				created_at: now(),
+				updated_at: now(),
+			};
+		});
+
+	if (workers.length > 1 && hasAmbiguousLaneSplitIntent(task))
+		throw new Error(
+			"ambiguous_team_lane_split: multi-worker team launch mentions lanes but does not provide explicit markdown lane sections such as `### Lane A — Title`",
+		);
+
 	return workers.map(worker => ({
 		id: `task-${worker.index}`,
 		subject: `Execute team brief (${worker.id})`,
@@ -2456,6 +2530,7 @@ export async function startGjcTeam(options: GjcTeamStartOptions): Promise<GjcTea
 		? { sessionName: "dry-run", windowIndex: "0", leaderPaneId: "%dry-run-leader", target: "dry-run:0" }
 		: readCurrentTmuxLeaderContext(tmuxCommand, env);
 	const initialWorkers = buildWorkers(options.workerCount, options.agentType, stateRoot);
+	const initialTasks = buildInitialTasks(options.task, initialWorkers);
 	const workers: GjcTeamWorker[] = [];
 	try {
 		for (const worker of initialWorkers)
@@ -2509,7 +2584,7 @@ export async function startGjcTeam(options: GjcTeamStartOptions): Promise<GjcTea
 		updated_at: createdAt,
 	});
 	await writePhase(dir, "starting");
-	for (const task of buildInitialTasks(options.task, config.workers)) await writeTask(dir, task);
+	for (const task of initialTasks) await writeTask(dir, task);
 	await appendEvent(dir, {
 		type: "team_started",
 		message: options.dryRun

package/src/gjc-runtime/ultragoal-guard.ts

@@ -3,6 +3,7 @@ import { DEFAULT_ULTRAGOAL_OBJECTIVE } from "./goal-mode-request";
 import {
 	computeUltragoalPlanGeneration,
 	getUltragoalPaths,
+	getUltragoalRunCompletionState,
 	hashStructuredValue,
 	readUltragoalLedger,
 	readUltragoalPlan,
@@ -246,7 +247,8 @@ export async function readUltragoalVerificationState(input: {
 			message: "Ultragoal has recorded review blockers; complete blocker work and rerun verification.",
 		};
 	}
-	if (plan.goals.some(goal => goal.status === "blocked" || goal.status === "failed")) {
+	const runState = getUltragoalRunCompletionState(plan);
+	if (runState.incompleteGoals.some(goal => goal.status === "blocked" || goal.status === "failed")) {
 		return {
 			state: "active_dirty_quality_gate",
 			message: "Ultragoal has blocked or failed goals; record blockers or rerun verification.",
@@ -259,7 +261,21 @@ export async function readUltragoalVerificationState(input: {
 			message: "Ultragoal aggregate completion requires a fresh final aggregate receipt.",
 		};
 	}
-	return validateCompletionReceipt({ plan, ledger, goal: receiptTarget.goal, receiptKind: receiptTarget.receiptKind });
+	const receiptDiagnostic = validateCompletionReceipt({
+		plan,
+		ledger,
+		goal: receiptTarget.goal,
+		receiptKind: receiptTarget.receiptKind,
+	});
+	if (receiptDiagnostic.state !== "active_verified_complete") return receiptDiagnostic;
+	if (runState.incompleteGoals.length > 0) {
+		return {
+			state: "active_missing_final_receipt",
+			message: `Ultragoal still has incomplete required goals: ${runState.incompleteGoals.map(goal => goal.id).join(", ")}. Run \`gjc ultragoal complete-goals\` to continue.`,
+			goalId: receiptTarget.goal.id,
+		};
+	}
+	return receiptDiagnostic;
 }
 
 export async function assertCanCompleteCurrentGoal(input: {