okstra 0.32.0 → 0.33.0

package/runtime/python/okstra_ctl/wizard.py

@@ -1314,11 +1314,15 @@ STEPS: list[Step] = [
                             and s.use_defaults is None),
          build=_build_defaults_or_custom, submit=_submit_defaults_or_custom,
          owns=("use_defaults",)),
-    # Customize branch — workers override only when the profile actually
-    # has analyser-candidate workers (required ∪ optional, minus report-writer).
+    # Worker roster is ALWAYS prompted (independent of the defaults /
+    # customize branch) when the profile has analyser-candidate workers
+    # (required ∪ optional, minus report-writer). Users repeatedly hit
+    # the failure mode where the lead silently picked "Use defaults"
+    # and the worker prompt never appeared — defaults should govern
+    # model choice, not worker selection. `implementation` task-type is
+    # still skipped because it runs lead + executor only.
     Step(S_WORKERS_OVERRIDE,
-         applies=lambda s: (s.use_defaults is False
-                            and s.task_type != "implementation"
+         applies=lambda s: (s.task_type != "implementation"
                             and any(
                                 w != "report-writer"
                                 for w in (s.profile_workers
@@ -1451,10 +1455,17 @@ def _identity_ready(s: WizardState) -> bool:
 def _ready_for_confirm(s: WizardState) -> bool:
     if s.use_defaults is None:
         return False
+    # Worker roster is required regardless of the defaults / customize
+    # branch. Skipping this check let the lead drop into confirm with no
+    # worker prompt ever shown — the very failure mode this gate exists
+    # to prevent.
+    workers_step = STEP_BY_ID[S_WORKERS_OVERRIDE]
+    if workers_step.applies(s):
+        return False
     if s.use_defaults:
         return True
     # customize: every customize-branch step must be answered or not-applicable.
-    custom_ids = [S_WORKERS_OVERRIDE, S_LEAD_MODEL, S_EXECUTOR_MODEL,
+    custom_ids = [S_LEAD_MODEL, S_EXECUTOR_MODEL,
                   S_CLAUDE_MODEL, S_CODEX_MODEL, S_GEMINI_MODEL,
                   S_REPORT_WRITER_MODEL, S_DIRECTIVE, S_RELATED_TASKS,
                   S_CLARIFICATION, S_PR_TEMPLATE, S_PR_TEMPLATE_SCOPE]

package/runtime/skills/okstra-team-contract/SKILL.md

@@ -245,7 +245,7 @@ Every worker result file MUST begin with a YAML frontmatter block. The values ar
 title: OKSTRA <Worker Role> Result - <task-key>
 id: "<task-key with ':' replaced by '-'>"
 aliases: ["<id>-<task-type>"]
-tags: ["obsidian", "okstra", "worker-result", "<task-type>"]
+tags: ["worker-result", "<task-type>"]
 taskType: "<task-type>"
 workerId: "<claude|codex|gemini|report-writer>"
 task-id: "<task-id>"
@@ -262,7 +262,7 @@ Concrete example for a `claude-worker` result on task-key `fontsninja-classifier
 title: OKSTRA Claude Worker Result - fontsninja-classifier-v2:DEV-9388:DEV-9429
 id: "fontsninja-classifier-v2-DEV-9388-DEV-9429"
 aliases: ["fontsninja-classifier-v2-DEV-9388-DEV-9429-implementation"]
-tags: ["obsidian", "okstra", "worker-result", "implementation"]
+tags: ["worker-result", "implementation"]
 taskType: "implementation"
 workerId: "claude"
 task-id: "DEV-9429"
@@ -374,7 +374,7 @@ without proceeding — this is the contractual replacement for the previous
 empty run-level error logs in production.
 
 - `cli-failure` events are recorded by the wrapper subagent itself (Codex / Gemini), but **directly to the run-level error log** via `okstra-error-log.py append-observed --error-type cli-failure ...` — NOT via the sidecar. The sidecar is an in-process tool-failure channel only.
-- **Wrapper invocation arity.** Both `okstra-codex-exec.sh` and `okstra-gemini-exec.sh` accept four required positional arguments plus an optional fifth `<role>`: `<project-root> <model> <prompt-path> <worktree-path> [<role>]`. The fourth (worktree) argument is **mandatory for implementation phase** and optional otherwise. For codex it becomes `--add-dir <worktree>` (sandbox write access); for gemini it is appended to `--include-directories`. Omitting it during implementation causes the codex sandbox to reject every Edit/Write targeting the worktree with EPERM. Workers extract the path from the `**Worktree:**` / `EXECUTOR_WORKTREE_PATH` / `cwd for every mutating command:` line in the lead prompt. The optional fifth `<role>` is the trace-pane label suffix (e.g. `codex-<role>-trace`); always pass the literal string `worker` so the dispatch is self-describing (the wrapper defaults to `worker` if omitted).
+- **Wrapper invocation arity.** Both `okstra-codex-exec.sh` and `okstra-gemini-exec.sh` accept four required positional arguments plus an optional fifth `<role>`: `<project-root> <model> <prompt-path> <worktree-path> [<role>]`. The fourth (worktree) argument is **mandatory for implementation phase** and optional otherwise. For codex it becomes `--add-dir <worktree>` (sandbox write access); for gemini it is appended to `--include-directories`. Omitting it during implementation causes the codex sandbox to reject every Edit/Write targeting the worktree with EPERM. Workers extract the path from the `**Worktree:**` / `EXECUTOR_WORKTREE_PATH` / `cwd for every mutating command:` line in the lead prompt. The optional fifth `<role>` is folded into both the caller (worker) pane title `<cli>-<role>-<pid>` and the sibling trace-pane title `<cli>-<role>-<pid>-trace` (e.g. `codex-worker-93421` ↔ `codex-worker-93421-trace`). `<pid>` is the wrapper's own PID and disambiguates concurrent dispatches of the same role. Always pass the literal string `worker` so the dispatch is self-describing (the wrapper defaults to `worker` if omitted).
 - **Background dispatch + polling contract (Codex / Gemini wrappers).** Both wrapper subagents MUST dispatch `okstra-codex-exec.sh` / `okstra-gemini-exec.sh` via `Bash(run_in_background: true)` and poll with `BashOutput(bash_id)` until the shell reports `status == "completed"`, capped at 30 minutes (1800s) of wall-clock elapsed time. `BashOutput` itself is the wait primitive — call it back-to-back; do NOT insert a standalone `sleep` between polls. The Claude Code harness blocks `sleep` calls of 5 seconds or longer as a circumvention vector and explicitly forbids chaining shorter sleeps inside until-loops to work around the block. Workers that hit the contract bug must NOT self-recover with `until ...; do sleep 2; done` wrappers — that path violates the harness anti-circumvention rule, even though it superficially "works". The legacy "single foreground `Bash` with 120000ms timeout" rule, and the subsequent "60-second cadence with `sleep 60` between polls" rule, are both retired. The current rule applies in **every phase** (analysis runs typically complete in 1–2 `BashOutput` calls, so there is no regression for short jobs). Recording responsibilities:
   - Successful completion: return the wrapper's accumulated stdout from the final `BashOutput`. No log entry.
   - Non-zero `exit_code` reported by `BashOutput`: record a `cli-failure` to the run-level error log with the real `exit_code` and observed `duration-ms`.