okstra 0.123.0 → 0.125.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +1 -0
- package/docs/architecture/storage-model.md +3 -1
- package/docs/architecture.md +16 -2
- package/docs/cli.md +3 -1
- package/docs/for-ai/README.md +41 -35
- package/docs/for-ai/skills/okstra-brief-gen.md +105 -105
- package/docs/for-ai/skills/okstra-container-build.md +61 -61
- package/docs/for-ai/skills/okstra-graphify.md +64 -0
- package/docs/for-ai/skills/okstra-inspect.md +87 -86
- package/docs/for-ai/skills/okstra-manager.md +32 -32
- package/docs/for-ai/skills/okstra-memory.md +49 -50
- package/docs/for-ai/skills/okstra-pr-gen.md +48 -0
- package/docs/for-ai/skills/okstra-rollup.md +58 -58
- package/docs/for-ai/skills/okstra-run.md +95 -95
- package/docs/for-ai/skills/okstra-schedule-gen.md +106 -106
- package/docs/for-ai/skills/okstra-setup.md +63 -64
- package/docs/for-ai/skills/okstra-user-response.md +48 -0
- package/docs/performance-improvement-plan-v2.md +6 -6
- package/docs/pr-template-usage.md +34 -34
- package/docs/project-structure-overview.md +91 -70
- package/docs/task-process/README.md +33 -33
- package/docs/task-process/common-flow.md +26 -26
- package/docs/task-process/error-analysis.md +20 -21
- package/docs/task-process/final-verification.md +41 -41
- package/docs/task-process/implementation-planning.md +33 -33
- package/docs/task-process/implementation.md +38 -38
- package/docs/task-process/release-handoff.md +46 -46
- package/docs/task-process/requirements-discovery.md +22 -23
- package/package.json +1 -1
- package/runtime/BUILD.json +2 -2
- package/runtime/agents/workers/antigravity-worker.md +4 -4
- package/runtime/agents/workers/claude-worker.md +2 -2
- package/runtime/agents/workers/codex-worker.md +4 -4
- package/runtime/agents/workers/report-writer-worker.md +4 -4
- package/runtime/bin/lib/okstra/usage.sh +1 -1
- package/runtime/prompts/coding-preflight/frameworks/node-server.md +1 -1
- package/runtime/prompts/launch.template.md +1 -1
- package/runtime/prompts/lead/convergence.md +10 -20
- package/runtime/prompts/lead/okstra-lead-contract.md +15 -17
- package/runtime/prompts/lead/plan-body-verification.md +18 -18
- package/runtime/prompts/lead/report-writer.md +46 -44
- package/runtime/prompts/lead/team-contract.md +11 -122
- package/runtime/prompts/profiles/_common-contract.md +15 -22
- package/runtime/prompts/profiles/_implementation-deliverable.md +1 -1
- package/runtime/prompts/profiles/_implementation-executor.md +1 -1
- package/runtime/prompts/profiles/_implementation-verifier.md +28 -2
- package/runtime/prompts/profiles/error-analysis.md +2 -2
- package/runtime/prompts/profiles/final-verification.md +1 -1
- package/runtime/prompts/profiles/implementation-planning.md +13 -13
- package/runtime/prompts/profiles/implementation.md +2 -1
- package/runtime/prompts/profiles/improvement-discovery.md +1 -1
- package/runtime/prompts/profiles/release-handoff.md +3 -3
- package/runtime/prompts/profiles/requirements-discovery.md +17 -18
- package/runtime/python/okstra_ctl/models.py +4 -2
- package/runtime/python/okstra_ctl/run.py +8 -2
- package/runtime/python/okstra_ctl/stage_fix_carry.py +112 -0
- package/runtime/schemas/final-report-v1.0.schema.json +6 -6
- package/runtime/skills/_fragments/bash-invocation-rule.md +1 -0
- package/runtime/skills/_fragments/preflight-outdated-cli.md +1 -0
- package/runtime/skills/_fragments/python-bootstrap-note.md +1 -0
- package/runtime/skills/okstra-brief-gen/SKILL.md +117 -122
- package/runtime/skills/okstra-container-build/SKILL.md +24 -14
- package/runtime/skills/okstra-graphify/SKILL.md +12 -4
- package/runtime/skills/okstra-inspect/SKILL.md +39 -747
- package/runtime/skills/okstra-inspect/facets/cost.md +84 -0
- package/runtime/skills/okstra-inspect/facets/error-zip.md +41 -0
- package/runtime/skills/okstra-inspect/facets/errors.md +69 -0
- package/runtime/skills/okstra-inspect/facets/history.md +90 -0
- package/runtime/skills/okstra-inspect/facets/logs.md +89 -0
- package/runtime/skills/okstra-inspect/facets/recap.md +96 -0
- package/runtime/skills/okstra-inspect/facets/report.md +61 -0
- package/runtime/skills/okstra-inspect/facets/status.md +145 -0
- package/runtime/skills/okstra-inspect/facets/time.md +56 -0
- package/runtime/skills/okstra-manager/SKILL.md +1 -1
- package/runtime/skills/okstra-memory/SKILL.md +3 -3
- package/runtime/skills/okstra-pr-gen/SKILL.md +3 -3
- package/runtime/skills/okstra-rollup/SKILL.md +12 -6
- package/runtime/skills/okstra-run/SKILL.md +49 -88
- package/runtime/skills/okstra-schedule-gen/SKILL.md +36 -30
- package/runtime/skills/okstra-setup/SKILL.md +1 -1
- package/runtime/skills/okstra-setup/references/project-config.md +17 -16
- package/runtime/skills/okstra-usage/SKILL.md +5 -2
- package/runtime/skills/okstra-user-response/SKILL.md +15 -3
- package/runtime/templates/prd/brief.template.md +92 -92
- package/runtime/templates/project-docs/task-index.template.md +1 -1
- package/runtime/templates/reports/error-analysis-input.template.md +1 -1
- package/runtime/templates/reports/fan-out-unit.template.md +6 -6
- package/runtime/templates/reports/final-verification-input.template.md +6 -6
- package/runtime/templates/reports/implementation-input.template.md +1 -1
- package/runtime/templates/reports/implementation-planning-input.template.md +1 -1
- package/runtime/templates/reports/improvement-discovery-input.template.md +1 -1
- package/runtime/templates/reports/quick-input.template.md +1 -1
- package/runtime/templates/reports/release-handoff-input.template.md +1 -1
- package/runtime/templates/reports/schedule.template.md +22 -22
- package/runtime/templates/reports/task-brief.template.md +3 -3
- package/runtime/templates/reports/user-response.template.md +20 -20
- package/runtime/templates/worker-prompt-preamble.md +111 -13
- package/runtime/validators/validate-schedule.py +1 -1
package/README.md
CHANGED
|
@@ -211,6 +211,7 @@ Major workflow changes added to `main` after 0.8.0:
|
|
|
211
211
|
- **Profile worker-roster validation** — `--workers <csv>` and the okstra-run Step 6 worker prompt accept only the worker IDs declared in the selected profile's `Required workers:` block. Requesting a worker absent from the profile—for example, `codex` or `antigravity` for `release-handoff`—fails with a clear error, and the interactive prompt shows only workers accepted by that profile.
|
|
212
212
|
- **Experimental Codex lead adapter** — `okstra codex-run <render-bundle args...>` prepares a `leadRuntime=codex` task bundle without launching Claude Code. `okstra codex-dispatch --project-root <dir> --run-manifest <path>` then executes the supported Codex-side roster subset: Codex and Antigravity CLI workers by default, with a Codex report writer available through `--enable-codex-report-writer --report-writer-codex-model <model>`. A successful Codex report-writer dispatch performs token/cost substitution, HTML view rendering, follow-up stub generation, and run validation in order. It shares the Claude lead path's manifest and schema and does not clone the project into a Codex-specific fork.
|
|
213
213
|
- **Multi-stage `implementation-planning` / `implementation`** — `implementation-planning` always produces a Stage Map and N stage sections. Each stage has no more than six steps, and stages with `depends-on (none)` can be implemented concurrently in separate `implementation` runs. Each `implementation` invocation runs a single stage, selected with `--stage <auto|N>`, and creates an evidence sidecar at `carry/stage-<N>.json` for automatic carry-in to the next stage. The `implementation-planning` run directory accumulates `consumers.jsonl` reverse links that record which run consumed each stage.
|
|
214
|
+
- **AI-prepared design preparation (implementation-planning → implementation)** — `implementation-planning` detects which stages need design input (domain contract, DB/table schema, external interface, transaction/consistency, transformation mapping, lifecycle, rollout/observability, manual user test) and has the AI draft a concrete proposal first, instead of handing the user an empty design document. Each item is assessed as `ready`, `provisional`, `blocked`, or `not-applicable`; a simple task may declare `no-design-inputs`. Phase 7 materializes an Okstra-owned request under `design-prep-requests/`, and `okstra design-prep <list|show|write>` or the okstra-run wizard records the confirmed answer as an **append-only** revision under `design-prep-inputs/`—neither path ever edits the approved planning snapshot. Before creating its worktree, `implementation` resolves only the items its selected stage cites in `stageRefs`: safe `provisional` assumptions are injected into the executor prompt so work proceeds, while an unsafe open decision makes only that stage wait or replan. A markerless legacy plan continues with a `legacy-unassessed` warning. Storage authorities: [`docs/architecture/storage-model.md`](docs/architecture/storage-model.md). CLI: [`docs/cli.md#okstra-design-prep`](docs/cli.md#okstra-design-prep).
|
|
214
215
|
- **Phase 6 plan-body verification (implementation-planning only)** — Immediately after the report-writer worker drafts the final report and before the user approval gate, the lead performs one post-verification round. It extracts `P-Opt-*`, `P-Step-*`, `P-Dep-*`, `P-Val-*`, and `P-Rb-*` plan items from the synthesized `## 5.5` implementation plan deliverables and asks every analyzer worker for an `AGREE`, `DISAGREE(a-e)`, or `SUPPLEMENT` verdict. The aggregate result is `passed`, `passed-with-dissent`, `blocked-by-disagreement`, or `aborted-non-result`. The frontmatter `approved` field is always published as `false`; a blocking result keeps it false and becomes a row in `## 1. Clarification Items`. For fast iteration, opt out with `--no-plan-verification`. Contract details: the "Plan-body verification mode" section of [`prompts/lead/convergence.md`](prompts/lead/convergence.md) and [`docs/cli.md#--no-plan-verification`](docs/cli.md#--no-plan-verification).
|
|
215
216
|
- **Brief as translation layer + Step 6.5 reporter batch confirmation** — `okstra-brief-gen` converts external input—an issue ticket, requirements document, or user message—verbatim and marks okstra-added content as labeled augmentation. Step 6.5 asks the user to confirm in one batch whether that conversion changed meaning and records the result in `Reporter Confirmations`. Every analysis profile requires this section before phase analysis begins; `validators/validate-brief.py` enforces the requirement.
|
|
216
217
|
- **Artifact-home rule (`.okstra/`)** — `<project>/.okstra/` is the only project artifact root owned by okstra. Anything outside this root is not okstra memory and may be read only when explicitly cited in Source Material or Reporter Confirmations. Writing outside the root requires the same explicit requested path. Internal equivalents are `glossary.md` for terminology and `decisions/<NNNN>-<slug>.md` for decision records, evaluated during `implementation-planning`.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Storage model & on-disk contracts
|
|
2
2
|
|
|
3
|
-
> Detailed storage and contract section from [`docs/
|
|
3
|
+
> Detailed storage and contract section from [`docs/architecture.md`](../architecture.md). This section was split out after the main document exceeded 1,000 lines.
|
|
4
4
|
|
|
5
5
|
## Storage model
|
|
6
6
|
|
|
@@ -231,6 +231,8 @@ Main contents:
|
|
|
231
231
|
This document is only a quick summary and is not the source of truth.
|
|
232
232
|
Always use `task-manifest.json` when checking canonical metadata.
|
|
233
233
|
|
|
234
|
+
The rendered `task-index.md` is an English-literal artifact. The headings, field labels, and `## Notes` footnote of the template (`templates/project-docs/task-index.template.md`) ship as English literals regardless of the `reportLanguage` setting, matching the okstra-schedule-gen schedule contract. The docs-publication pipeline's Hangul check (`npm run docs:validate`) enforces this contract.
|
|
235
|
+
|
|
234
236
|
## Run manifest contract
|
|
235
237
|
|
|
236
238
|
Each execution records the current run contract in the resolved `<run-dir>/manifests/run-manifest-<task-type>-<seq>.json`. The non-stage or stage-qualified rule above determines `<run-dir>`.
|
package/docs/architecture.md
CHANGED
|
@@ -225,6 +225,20 @@ implementation-planning Phase 6
|
|
|
225
225
|
|
|
226
226
|
Resolution is stage-scoped: only items whose `stageRefs` include the selected stage participate, so an unsafe open decision blocks that stage rather than unrelated ready stages. `no-design-inputs` resolves to `proceed`. Plans created before the `implementation-design-prep-v1` report contract also proceed with a `legacy-unassessed` warning and are not rewritten.
|
|
227
227
|
|
|
228
|
+
### Fix-run incremental reverification
|
|
229
|
+
|
|
230
|
+
When an implementation run is prepared on a stage whose latest final-report data.json carries one or more verifier `FAIL` verdicts, prep derives a fix-run carry (`okstra_ctl.stage_fix_carry`) — previous report path, previous run HEAD, failed verifiers, carried blocking findings, routing recommendation — and injects it into the rendered analysis profile as a "Fix-Run Carry" block via the `{{FIX_RUN_CONTEXT}}` token. Verifiers then keep the full validation-command re-run but narrow the static design/test-quality sweep to `git diff <prev-head>..HEAD` plus a mandatory re-check of each carried finding, and the report writer authors the new data.json incrementally by copying the previous one and updating only the changed blocks (`prompts/profiles/_implementation-verifier.md` § Fix-run incremental scope, `prompts/lead/report-writer.md` § Fix-run incremental authoring). A first run on a stage, or a rerun after a PASS, renders the token empty and behaves as before.
|
|
231
|
+
|
|
232
|
+
### Clarification & decision-capture discipline
|
|
233
|
+
|
|
234
|
+
okstra runs a single cross-phase discipline for turning open questions into resolved decisions and durable memory. It is not one module — it is enforced at three sites that share one vocabulary, deliberately split across an interactive layer and a headless layer:
|
|
235
|
+
|
|
236
|
+
- **Interactive sharpening (bounded)** — `skills/okstra-brief-gen/SKILL.md` Step 4 asks one question at a time, each carrying a recommended answer, resolving facts from the codebase before asking. It is intentionally a *bounded* pass, not a decision-making interview: brief is a pre-discovery artifact, so the deep decision walk is pushed downstream.
|
|
237
|
+
- **Headless decision-tree walk** — the `requirements-discovery` and `implementation-planning` profiles walk the decision tree one branch at a time, emitting a static `Clarification Items` table (recommended answer `(a)` + alternatives `(b) (c)`) rather than a live interview, because these phases are headless batch runs. Facts answerable by `Read` / `Grep` are resolved with `path:line` evidence and never escalated.
|
|
238
|
+
- **Decision capture** — resolved terminology becomes okstra memory at `<PROJECT_ROOT>/.okstra/glossary.md` (approval-gated, `okstra-brief-gen` Step 4.5). A decision is recorded as `<PROJECT_ROOT>/.okstra/decisions/<NNNN>-<slug>.md` only when it is hard to reverse, surprising without context, and the result of a real trade-off; `implementation-planning` is the sole owner of that evaluation and `validators/validate-run.py` enforces materialization.
|
|
239
|
+
|
|
240
|
+
When changing any one site, keep the shared vocabulary (recommended-answer, codebase-first, glossary, decision-record) aligned across all three so the discipline does not drift.
|
|
241
|
+
|
|
228
242
|
### Concurrency
|
|
229
243
|
|
|
230
244
|
Two types of file locks handle all concurrency.
|
|
@@ -596,7 +610,7 @@ Approval format (code truth: `APPROVED_FRONTMATTER_PATTERN` in `scripts/okstra_c
|
|
|
596
610
|
- Exactly one line inside the final report's leading `---` YAML fence: `approved: true` or `approved: false`
|
|
597
611
|
- Case-insensitive. The report writer always publishes `approved: false`; implementation becomes available after the user toggles it to `true`
|
|
598
612
|
|
|
599
|
-
To treat the CLI invocation itself as approval without editing the approval line directly, add the `--approve` flag. okstra toggles the `approved` field in the `--approved-plan` file's frontmatter to `true`, appends an audit line, and continues into the implementation phase (the former `--ack-approved` alias was removed in 0.8.0). See [`docs/
|
|
613
|
+
To treat the CLI invocation itself as approval without editing the approval line directly, add the `--approve` flag. okstra toggles the `approved` field in the `--approved-plan` file's frontmatter to `true`, appends an audit line, and continues into the implementation phase (the former `--ack-approved` alias was removed in 0.8.0). See [`docs/cli.md`](cli.md#--approve) for details.
|
|
600
614
|
|
|
601
615
|
```bash
|
|
602
616
|
scripts/okstra.sh --task-type implementation --workers claude,codex,antigravity --project-id <project-id> --task-group <task-group> --task-id <task-id> --task-brief <brief-path> --approved-plan <runs/implementation-planning/.../reports/final-report.md>
|
|
@@ -772,7 +786,7 @@ Each validator blocks the phase with a `contract-violated` exit code when a cont
|
|
|
772
786
|
- The run directory is organized into typed subdirectories such as `manifests/`, `state/`, `prompts/`, `reports/`, `status/`, `sessions/`, and `worker-results/`; prompt snapshots are prepared under `prompts/` first.
|
|
773
787
|
- Claude creates workers and collects results.
|
|
774
788
|
- The standard workflow uses a `Claude lead` with default workers `Claude worker`, `Codex worker`, and `Report writer worker`; `Antigravity worker` is optional and included only when explicitly requested.
|
|
775
|
-
- Worker models can be overridden with `--lead-model`, `--claude-model`, `--codex-model`, `--antigravity-model`, and `--report-writer-model`; defaults are centrally managed through `OKSTRA_DEFAULT_*` environment variables. Fallback defaults are `Claude lead
|
|
789
|
+
- Worker models can be overridden with `--lead-model`, `--claude-model`, `--codex-model`, `--antigravity-model`, and `--report-writer-model`; defaults are centrally managed through `OKSTRA_DEFAULT_*` environment variables. Fallback defaults are `Claude lead`=`opus`, `Claude worker`=`opus`, `Codex worker`=`gpt-5.6-sol`, `Report writer worker`=`sonnet`, and `Antigravity worker`=`auto`.
|
|
776
790
|
- For `--task-type implementation`, select the provider that takes the Executor role with `--executor <claude|codex|antigravity>` (or `OKSTRA_DEFAULT_EXECUTOR`, fallback `claude`). Only the Executor may mutate project files. The other two providers and the Executor's own provider are each dispatched as verifiers in separate CLI sessions (session isolation preserves the self-review safeguard). The Executor's model reuses the selected provider's worker-model flag (`--claude-model` / `--codex-model` / `--antigravity-model`). Provider / displayName / workerAgent / model are recorded in the run-manifest `teamContract.executor` block.
|
|
777
791
|
- Worktree cwd injection by Executor: Codex / Antigravity executors pin cwd to the worktree at the CLI layer through wrappers (`okstra-codex-exec.sh -C` / `okstra-antigravity-exec.sh --include-directories`). Because the Bash tool has no per-call cwd argument, the Claude executor prefixes cwd-sensitive toolchain invocations (`cargo`/`npm`/`pnpm`/`bun`/`pytest`/`make`/`go`) with `cd {{EXECUTOR_WORKTREE_PATH}} && <cmd>` in the same Bash invocation. Wrapping in `bash -lc`/`bash -c` is prohibited because it hides the leading `cd` token and defeats permission auto-allow. Prefer working-directory flags such as `git -C` or `cargo --manifest-path` when available. See the *Executor Worktree* block in `prompts/profiles/implementation.md` and the Executor exception in `agents/workers/claude-worker.md` for details.
|
|
778
792
|
- The project-level current-task convenience pointer is `.okstra/discovery/latest-task.json`.
|
package/docs/cli.md
CHANGED
|
@@ -369,7 +369,7 @@ When omitted, it uses the central default `OKSTRA_DEFAULT_ANTIGRAVITY_MODEL`, fa
|
|
|
369
369
|
### `--report-writer-model`
|
|
370
370
|
|
|
371
371
|
Selects the model used by the `Report writer worker`.
|
|
372
|
-
When omitted, it uses the central default `OKSTRA_DEFAULT_REPORT_WRITER_MODEL`, falling back to the lead
|
|
372
|
+
When omitted, it uses the central default `OKSTRA_DEFAULT_REPORT_WRITER_MODEL`, falling back to `sonnet`. The report writer does not vote in convergence, so its default sits below the lead tier to cut report-generation wall-clock; pass `--report-writer-model opus` to restore the previous behavior.
|
|
373
373
|
|
|
374
374
|
The central-default environment variables are:
|
|
375
375
|
|
|
@@ -646,6 +646,8 @@ The `okstra` Node CLI (`bin/okstra`) provides both installer/admin commands and
|
|
|
646
646
|
| `okstra task-list [--project-root <path>]` | Combine `list_project_tasks` and `read_latest_task` into JSON containing the task catalog and latest task |
|
|
647
647
|
| `okstra task-show <task-key> [--project-root <path>]` | Summarize workflow, phase, status, and artifacts from the Task Read-Side Snapshot |
|
|
648
648
|
| `okstra stage-map <task-key> [--cwd <dir>\|--project <dir>]` | Dump the task's implementation-planning Stage Map as JSON: `{ ok, taskKey, taskRoot, stages:[{stage_number,title,depends_on,step_count}], doneStages:[int] }`. `stages` is `[]` when the task has no implementation-planning Stage Map. `doneStages` is read from the implementation-planning stage consumer state (with carry recovery). This is the read-side source the `okstra-schedule-gen` skill uses to derive stage units and their dependency closure |
|
|
649
|
+
| `okstra incremental-scope <args…>` | Decide re-verify vs carry-forward scope for an `implementation-planning` clarification re-run. Thin shim into `scripts/okstra_ctl/incremental_scope.py` (deterministic pure function): it reads the dependency graph from the prior run `data.json`'s `implementationPlanning.stageMap` and returns `mode:"incremental"` only when the base-ref SHA is unchanged and the affected stages' `downstream_stage_closure` covers at most half of all stages; otherwise it signals a full re-run. Used to bound the cost of a clarification re-run |
|
|
650
|
+
| `okstra incremental-carry <args…>` | Merge carried-forward plan-item verdicts into an incremental re-run. Thin shim into `scripts/okstra_ctl/incremental_carry.py`: it takes the prior run's plan-item verdicts that the current run does not re-verify and merges them into the current `data.json` tagged with `carriedForwardFromSeq`. A `schemaVersion` drift raises `CarryError` and exits non-zero to force a full fallback. Runs after `incremental-scope` returns `mode:"incremental"` |
|
|
649
651
|
| `okstra set-work-status <token> <todo\|in-progress\|blocked\|done> [--note <text>] [--task-group <g>] [--project-root <dir>]` | Update user-managed `workStatus` in task-manifest.json, along with `workStatusUpdatedAt` and, when `--note` is supplied, `workStatusNote`. `<token>` is a full task key or bare task ID. It uses the manifest renderer's serialization rules and returns `stage:"ambiguous"` plus `matches[]` when ambiguous |
|
|
650
652
|
| `okstra worktree-lookup <task-key>` | Return the `worktree_registry.lookup` result: reserved path, branch, base ref, and current status |
|
|
651
653
|
| `okstra plan-validate <plan-path>` | Run `_validate_approved_plan` and report frontmatter `approved` recognition plus unresolved Blocks=approval rows |
|
package/docs/for-ai/README.md
CHANGED
|
@@ -1,52 +1,55 @@
|
|
|
1
1
|
# Okstra Skills AI Manuals
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
This directory is a compressed manual for an AI to quickly select and precisely run okstra public skills. The authoritative contract is `skills/*/SKILL.md`; this document is the operational guide for the AI. When the source skills, templates, validators, or CLI registry conflict, prefer the source skills and the actual validator/CLI implementation.
|
|
4
4
|
|
|
5
|
-
##
|
|
5
|
+
## Verified Sources
|
|
6
6
|
|
|
7
|
-
-
|
|
8
|
-
-
|
|
9
|
-
- CLI
|
|
10
|
-
- brief
|
|
11
|
-
- schedule
|
|
12
|
-
- brief
|
|
13
|
-
- schedule
|
|
7
|
+
- Public skill list: [`src/lib/skill-catalog.mjs`](../../src/lib/skill-catalog.mjs)
|
|
8
|
+
- Skill sources: [`skills/`](../../skills/)
|
|
9
|
+
- CLI command surface: [`src/cli-registry.mjs`](../../src/cli-registry.mjs)
|
|
10
|
+
- brief template: [`templates/reports/brief.template.md`](../../templates/reports/brief.template.md)
|
|
11
|
+
- schedule template: [`templates/reports/schedule.template.md`](../../templates/reports/schedule.template.md)
|
|
12
|
+
- brief validator: [`validators/validate-brief.py`](../../validators/validate-brief.py)
|
|
13
|
+
- schedule validator: [`validators/validate-schedule.py`](../../validators/validate-schedule.py)
|
|
14
14
|
|
|
15
|
-
##
|
|
15
|
+
## Skill Routing
|
|
16
16
|
|
|
17
|
-
|
|
|
17
|
+
| User intent | Skill to use | Manual |
|
|
18
18
|
|---|---|---|
|
|
19
|
-
|
|
|
20
|
-
|
|
|
21
|
-
|
|
|
22
|
-
|
|
|
23
|
-
|
|
|
24
|
-
| task-group(
|
|
19
|
+
| Install/initialize okstra on a new project or a new machine | `okstra-setup` | [`skills/okstra-setup.md`](skills/okstra-setup.md) |
|
|
20
|
+
| Turn requirements, tickets, links, a codebase scan, or an error-zip into an okstra input brief | `okstra-brief-gen` | [`skills/okstra-brief-gen.md`](skills/okstra-brief-gen.md) |
|
|
21
|
+
| Start an okstra run or execute the next phase in the current Claude Code session | `okstra-run` | [`skills/okstra-run.md`](skills/okstra-run.md) |
|
|
22
|
+
| Manage okstra tasks across multiple projects — bundling, assignment, sync snapshots, child launch packets | `okstra-manager` | [`skills/okstra-manager.md`](skills/okstra-manager.md) |
|
|
23
|
+
| Check status, history, report, time, logs, cost, errors, error-zip, recap | `okstra-inspect` | [`skills/okstra-inspect.md`](skills/okstra-inspect.md) |
|
|
24
|
+
| Collect and aggregate the results of multiple task runs across a task-group (or the whole project) into a synthesized summary | `okstra-rollup` | [`skills/okstra-rollup.md`](skills/okstra-rollup.md) |
|
|
25
25
|
| Project-wide recent run coverage, tokens, known cost, CPU, and wall-clock usage by task type | `okstra-usage` | [`skills/okstra-usage.md`](skills/okstra-usage.md) |
|
|
26
|
-
|
|
|
27
|
-
|
|
|
28
|
-
| implementation
|
|
26
|
+
| Generate a client-facing work schedule for a whole task-group | `okstra-schedule-gen` | [`skills/okstra-schedule-gen.md`](skills/okstra-schedule-gen.md) |
|
|
27
|
+
| Store or search conversations/decisions/preferences/requirements in the global Memory Book | `okstra-memory` | [`skills/okstra-memory.md`](skills/okstra-memory.md) |
|
|
28
|
+
| Manage the implementation-task worktree-based docker compose user-test environment | `okstra-container-build` | [`skills/okstra-container-build.md`](skills/okstra-container-build.md) |
|
|
29
|
+
| Answer the unresolved clarification questions an okstra run left behind in-session and record the approval gate | `okstra-user-response` | [`skills/okstra-user-response.md`](skills/okstra-user-response.md) |
|
|
30
|
+
| Build and query a knowledge graph over the project's own `.okstra` memory (reports, decision records, glossary) | `okstra-graphify` | [`skills/okstra-graphify.md`](skills/okstra-graphify.md) |
|
|
31
|
+
| Register a PR body template or generate a PR description from a branch diff (global, git repository) | `okstra-pr-gen` | [`skills/okstra-pr-gen.md`](skills/okstra-pr-gen.md) |
|
|
29
32
|
|
|
30
|
-
##
|
|
33
|
+
## Shared Execution Rules
|
|
31
34
|
|
|
32
|
-
1.
|
|
33
|
-
2. `okstra <subcmd>`
|
|
34
|
-
3. `okstra-setup
|
|
35
|
-
4.
|
|
36
|
-
5. `runtime
|
|
37
|
-
6. tracker, URL,
|
|
38
|
-
7.
|
|
35
|
+
1. Run commands as separate Bash calls whenever the source skill requires it. In particular, do not wrap `okstra preflight --runtime claude-code --json`, `okstra wizard ...`, or `okstra container ...` calls in `&&`, `||`, `$(...)`, a leading variable assignment, `eval`, or `export`.
|
|
36
|
+
2. An `okstra <subcmd>` call bootstraps its own Python path. Unless a skill states otherwise, do not build `okstra paths --shell` or `export PYTHONPATH=...`.
|
|
37
|
+
3. Most skills except `okstra-setup` do not use an `npx` fallback. If the runtime is missing, tell the user to run `/okstra-setup` and stop. But if it fails with `unknown command: <cmd>`, the `okstra` binary on PATH is older than the skill — point the user to `npm i -g okstra@latest` rather than `/okstra-setup`, and stop.
|
|
38
|
+
4. Project artifacts go under `<PROJECT_ROOT>/.okstra/` by default. The exception is `okstra-memory`, which uses the global user memory `~/.okstra/memory-book/`.
|
|
39
|
+
5. `runtime/` is build output. When fixing a source skill or template, edit the source under `skills/`, `templates/`, `validators/`, `scripts/`, `src/` and apply it via a build.
|
|
40
|
+
6. Do not guess the contents of a tracker, URL, file, report, log, zip, template, or validator. Use only what you have confirmed by reading or running with a tool.
|
|
41
|
+
7. Read-side skills also produce some artifacts. `okstra-inspect errors` produces an error report Markdown, and `okstra-inspect error-zip` produces an anonymized zip. Even in these cases, keep the CLI stdout JSON as the source of truth.
|
|
39
42
|
|
|
40
|
-
## AI
|
|
43
|
+
## The Order the AI Reads In
|
|
41
44
|
|
|
42
|
-
1.
|
|
43
|
-
2.
|
|
44
|
-
3.
|
|
45
|
-
4. brief
|
|
45
|
+
1. Pick a skill in this file.
|
|
46
|
+
2. Read only the matching `docs/for-ai/skills/<skill>.md`.
|
|
47
|
+
3. If the skill requires actual execution, confirm the relevant step in the source [`skills/<skill>/SKILL.md`](../../skills/).
|
|
48
|
+
4. When writing a brief or schedule, also confirm the template and the validator.
|
|
46
49
|
|
|
47
|
-
##
|
|
50
|
+
## Public Skill List
|
|
48
51
|
|
|
49
|
-
|
|
52
|
+
The public skills listed in this AI manual are the following 13:
|
|
50
53
|
|
|
51
54
|
- `okstra-setup`
|
|
52
55
|
- `okstra-brief-gen`
|
|
@@ -58,3 +61,6 @@
|
|
|
58
61
|
- `okstra-usage`
|
|
59
62
|
- `okstra-schedule-gen`
|
|
60
63
|
- `okstra-container-build`
|
|
64
|
+
- `okstra-user-response`
|
|
65
|
+
- `okstra-graphify`
|
|
66
|
+
- `okstra-pr-gen`
|
|
@@ -1,72 +1,72 @@
|
|
|
1
1
|
# okstra-brief-gen AI Manual
|
|
2
2
|
|
|
3
|
-
##
|
|
3
|
+
## Source
|
|
4
4
|
|
|
5
|
-
-
|
|
6
|
-
- brief
|
|
5
|
+
- Skill source: [`skills/okstra-brief-gen/SKILL.md`](../../../skills/okstra-brief-gen/SKILL.md)
|
|
6
|
+
- brief template: [`templates/reports/brief.template.md`](../../../templates/reports/brief.template.md)
|
|
7
7
|
- brief validator: [`validators/validate-brief.py`](../../../validators/validate-brief.py)
|
|
8
8
|
- lens enum SSOT: [`scripts/okstra_ctl/improvement_lenses.py`](../../../scripts/okstra_ctl/improvement_lenses.py)
|
|
9
9
|
|
|
10
|
-
##
|
|
10
|
+
## Purpose
|
|
11
11
|
|
|
12
|
-
`okstra-brief-gen
|
|
12
|
+
`okstra-brief-gen` produces a task brief to feed into the okstra pipeline. A brief is a pre-discovery artifact. It is not a document that turns requirements into an implementation plan; it is a handoff document that separates the reporter's verbatim material from the AI-verified evidence/interpretation using labels, so the next phase can start without questions.
|
|
13
13
|
|
|
14
|
-
|
|
14
|
+
Output location:
|
|
15
15
|
|
|
16
16
|
```text
|
|
17
17
|
<PROJECT_ROOT>/.okstra/briefs/<task-group>/<brief-id>.md
|
|
18
18
|
<PROJECT_ROOT>/.okstra/briefs/<task-group>/sub/.../<brief-id>.md
|
|
19
19
|
```
|
|
20
20
|
|
|
21
|
-
##
|
|
21
|
+
## Three variants
|
|
22
22
|
|
|
23
|
-
| Variant |
|
|
23
|
+
| Variant | Input | Recommended next phase |
|
|
24
24
|
|---|---|---|
|
|
25
|
-
| Reporter input |
|
|
25
|
+
| Reporter input | files, tickets, URLs, conversation/free text | `requirements-discovery` or `error-analysis` |
|
|
26
26
|
| Codebase scan | scan scope, priority lenses, candidate cap, context | `improvement-discovery` |
|
|
27
|
-
| Error feedback |
|
|
27
|
+
| Error feedback | a single error cluster from the zip produced by `okstra error-zip` | `error-analysis` |
|
|
28
28
|
|
|
29
|
-
##
|
|
29
|
+
## Core invariants
|
|
30
30
|
|
|
31
|
-
1. Source Material
|
|
32
|
-
2. AI
|
|
33
|
-
3. augmentation
|
|
34
|
-
4. `intent-inference
|
|
35
|
-
5. `terminology-mapping` augmentation
|
|
36
|
-
6. reporter
|
|
37
|
-
7.
|
|
38
|
-
8.
|
|
39
|
-
9. `Open Questions
|
|
31
|
+
1. Source Material is a verbatim-preservation area. Do not paraphrase, summarize, or reorder.
|
|
32
|
+
2. The AI's interpretation, file links, terminology mapping, and format conversion all go under `Augmentation` or a `> augmented:` blockquote.
|
|
33
|
+
3. An augmentation carries one of four labels: `evidence-link`, `format-conversion`, `terminology-mapping`, `intent-inference`.
|
|
34
|
+
4. `intent-inference` is paired with `intent-check:` in `Open Questions`. This relationship is checked by `validators/validate-brief.py`.
|
|
35
|
+
5. A `terminology-mapping` augmentation is paired with `terminology:` in `Open Questions` (validator-checked). Exception: the Step 4.5 result markers `applied glossary:` / `skipped glossary:` need no paired row.
|
|
36
|
+
6. Questions only the reporter can answer are collected in Step 6.5 and recorded verbatim under `## Reporter Confirmations`.
|
|
37
|
+
7. Ticket split/link/order relations go in the structured table of `## Related Task Graph`. Do not infer work order from parent-id alone.
|
|
38
|
+
8. Every okstra-owned write stays inside `<PROJECT_ROOT>/.okstra/`. External files are read only when the reporter explicitly cited them as source.
|
|
39
|
+
9. Every row in `Open Questions` starts with one of five prefixes: `general:`, `terminology:`, `intent-check:`, `conversion-block:`, `adr-candidate:` (validator-enforced). `adr-candidate:` is only a signal — the decision file is written by `implementation-planning` into `<PROJECT_ROOT>/.okstra/decisions/`.
|
|
40
40
|
|
|
41
41
|
## Preflight
|
|
42
42
|
|
|
43
|
-
|
|
43
|
+
Run as a single call.
|
|
44
44
|
|
|
45
45
|
```bash
|
|
46
46
|
okstra preflight --runtime claude-code --json
|
|
47
47
|
```
|
|
48
48
|
|
|
49
|
-
runtime
|
|
49
|
+
If runtime or project setup is missing, guide the user to `/okstra-setup` and stop. This skill does not use an `npx` fallback.
|
|
50
50
|
|
|
51
|
-
##
|
|
51
|
+
## Input collection
|
|
52
52
|
|
|
53
53
|
### Reporter input
|
|
54
54
|
|
|
55
|
-
|
|
55
|
+
More than one source type is allowed, but each source is stored as a separate block under `Source Material`.
|
|
56
56
|
|
|
57
|
-
- File:
|
|
58
|
-
- Issue tracker ticket: Linear/Jira/GitHub/Notion
|
|
59
|
-
- Link URL: fetch
|
|
60
|
-
- User input:
|
|
57
|
+
- File: read the entire file and insert it as-is.
|
|
58
|
+
- Issue tracker ticket: detect Linear/Jira/GitHub/Notion and use MCP or the `gh` CLI. If no access tool is available, ask the user to paste the body or skip.
|
|
59
|
+
- Link URL: fetch it. On failure / login wall / body truncation, ask the user to paste.
|
|
60
|
+
- User input: if conversation context is sufficient, use conversation synthesis; if thin, take a single free-text input.
|
|
61
61
|
|
|
62
|
-
|
|
62
|
+
If a ticket has children/sub-tasks, ask once at the parent how to handle the tree.
|
|
63
63
|
|
|
64
|
-
- Full tree:
|
|
65
|
-
- Parent only: child
|
|
66
|
-
- Selected:
|
|
64
|
+
- Full tree: generate a brief per descendant.
|
|
65
|
+
- Parent only: put child keys/URLs in Related Artifacts and leave a `parent-of` edge in `Related Task Graph`.
|
|
66
|
+
- Selected: recurse only into the chosen direct-child branch.
|
|
67
67
|
|
|
68
|
-
|
|
69
|
-
Full tree
|
|
68
|
+
During recursion, manage the visited set as `<tracker>:<ticket-id>`, and on re-run reseed from the existing brief frontmatter's `ticket-id` + `source-type`.
|
|
69
|
+
When Full tree or Selected produces multiple briefs, copy the same `Related Task Graph` into every generated brief. That way, even if only one child brief is passed to a downstream phase, the split topology, predecessor/successor relations, and de-duplication signals are preserved.
|
|
70
70
|
|
|
71
71
|
`Related Task Graph` table schema:
|
|
72
72
|
|
|
@@ -77,39 +77,39 @@ Full tree 또는 Selected로 여러 brief를 만들면 모든 생성 brief에
|
|
|
77
77
|
| To | task key, brief id, tracker id, or URL |
|
|
78
78
|
| Direction | `directed` or `undirected` |
|
|
79
79
|
| Source | tracker linked issue, task-list checkbox, reporter statement, manual split, prior okstra task |
|
|
80
|
-
| Impact | downstream phase
|
|
80
|
+
| Impact | meaning the downstream phase must preserve |
|
|
81
81
|
|
|
82
|
-
`depends-on`, `blocks`, parent/child, follow-up, split
|
|
82
|
+
`depends-on`, `blocks`, parent/child, follow-up, and split relations are `directed`. `duplicates` and `related-to` are `undirected`. Do not create a relation with no source.
|
|
83
83
|
|
|
84
84
|
### Codebase scan
|
|
85
85
|
|
|
86
|
-
|
|
86
|
+
Collected values:
|
|
87
87
|
|
|
88
|
-
- `scan_scope`:
|
|
89
|
-
- `priority_lenses`: `LENSES` enum
|
|
90
|
-
- `out_of_scope`:
|
|
91
|
-
- `candidate_cap`: 1
|
|
88
|
+
- `scan_scope`: a list of real paths inside the project.
|
|
89
|
+
- `priority_lenses`: 1–4 of the `LENSES` enum.
|
|
90
|
+
- `out_of_scope`: optional.
|
|
91
|
+
- `candidate_cap`: 1–12, default 8.
|
|
92
92
|
- context, desired outcome, constraints.
|
|
93
93
|
|
|
94
|
-
|
|
94
|
+
Verify path existence, the lens enum subset, and the candidate-cap range before writing. Final validation is done by `validate-brief.py`, which checks `scope: codebase`, `Scan Scope`, and `Priority Lenses`.
|
|
95
95
|
|
|
96
96
|
### Error feedback
|
|
97
97
|
|
|
98
|
-
|
|
98
|
+
The input is the zip produced by `okstra error-zip --out <path>`.
|
|
99
99
|
|
|
100
|
-
|
|
100
|
+
Processing:
|
|
101
101
|
|
|
102
|
-
1. zip
|
|
103
|
-
2.
|
|
104
|
-
3.
|
|
105
|
-
4.
|
|
106
|
-
5.
|
|
102
|
+
1. Confirm the zip contains `report.md` and `errors/anonymized.jsonl`.
|
|
103
|
+
2. Pick exactly one cluster from the frequent-cluster table.
|
|
104
|
+
3. Move only the chosen cluster's anonymized records into Source Material.
|
|
105
|
+
4. Do not mix different errorTypes into one brief.
|
|
106
|
+
5. Set the next-step guidance to `error-analysis`.
|
|
107
107
|
|
|
108
|
-
## task-group
|
|
108
|
+
## task-group and filename
|
|
109
109
|
|
|
110
|
-
task-group
|
|
110
|
+
For task-group, show existing-group recommendations first. Call `okstra task-list`, extract the distinct `taskGroup` values from `tasks[]` in most-recent order, and offer the 2 most recent + enter-directly. In tracker recursion, task-group must be obtained before building any child path.
|
|
111
111
|
|
|
112
|
-
|
|
112
|
+
File path rule:
|
|
113
113
|
|
|
114
114
|
```text
|
|
115
115
|
depth 0: .okstra/briefs/<task-group>/<ticket-id>-<file-title>.md
|
|
@@ -117,56 +117,56 @@ depth 1: .okstra/briefs/<task-group>/sub/<ticket-id>-<file-title>.md
|
|
|
117
117
|
depth N: .okstra/briefs/<task-group>/<sub/ repeated N>/<ticket-id>-<file-title>.md
|
|
118
118
|
```
|
|
119
119
|
|
|
120
|
-
frontmatter
|
|
120
|
+
The frontmatter's `depth` must equal the number of `sub/` segments in the path. The validator checks this.
|
|
121
121
|
|
|
122
|
-
|
|
122
|
+
On collision, the default is Skip. You may offer Append suffix or Overwrite. Do not silently perform a bulk overwrite in tracker multi-generation.
|
|
123
123
|
|
|
124
124
|
## Domain alignment
|
|
125
125
|
|
|
126
|
-
|
|
126
|
+
First look at okstra's internal memory.
|
|
127
127
|
|
|
128
128
|
- `<PROJECT_ROOT>/.okstra/glossary.md`
|
|
129
129
|
- `<PROJECT_ROOT>/.okstra/decisions/`
|
|
130
|
-
-
|
|
130
|
+
- the related task's `history/fix-cycles.jsonl`
|
|
131
131
|
|
|
132
|
-
|
|
132
|
+
Read external domain docs only when the reporter explicitly cited them as source material. Record conflicting/ambiguous terms under `Augmentation > Domain alignment` with `terminology-mapping`, and put a `terminology:` row in `Open Questions`.
|
|
133
133
|
|
|
134
|
-
|
|
134
|
+
When a file path or symbol is mentioned, find the actual in-repo reference with `Read`/`Grep` and record it as `evidence-link`. If it cannot be mapped, do not guess — leave a `conversion-block:` row.
|
|
135
135
|
|
|
136
136
|
## Sharpening pass
|
|
137
137
|
|
|
138
|
-
full interview
|
|
138
|
+
Do not run a full interview. Ask only about gaps that source and codebase cannot fill.
|
|
139
139
|
|
|
140
|
-
|
|
140
|
+
Default budget:
|
|
141
141
|
|
|
142
|
-
-
|
|
143
|
-
- terminology/fuzzy disambiguation
|
|
144
|
-
-
|
|
145
|
-
- codebase-scan
|
|
142
|
+
- at most 1 question per section the source skill designates as fill-in.
|
|
143
|
+
- at most 2 questions for terminology/fuzzy disambiguation.
|
|
144
|
+
- at most 6 questions overall.
|
|
145
|
+
- codebase-scan up to 8 questions.
|
|
146
146
|
|
|
147
|
-
|
|
147
|
+
Prefer codebase-first checks over questions. Put remaining gaps in `_(none)_` or `Open Questions`.
|
|
148
148
|
|
|
149
|
-
## template
|
|
149
|
+
## template writing rules
|
|
150
150
|
|
|
151
|
-
|
|
151
|
+
The template `templates/reports/brief.template.md` is the SSOT. Follow the section order, frontmatter keys, top blockquote shape, and HTML comment guidance.
|
|
152
152
|
|
|
153
|
-
Reporter input
|
|
153
|
+
Reporter input and Error feedback:
|
|
154
154
|
|
|
155
|
-
- `## Source Material
|
|
156
|
-
- `## Problem / Symptom
|
|
157
|
-
- `## Scan Scope`, `## Priority Lenses
|
|
155
|
+
- keep `## Source Material`.
|
|
156
|
+
- keep `## Problem / Symptom`.
|
|
157
|
+
- omit `## Scan Scope`, `## Priority Lenses`.
|
|
158
158
|
|
|
159
159
|
Codebase scan:
|
|
160
160
|
|
|
161
|
-
-
|
|
162
|
-
- `## Source Material`, `## Problem / Symptom
|
|
163
|
-
- `## Scan Scope`, `## Priority Lenses
|
|
161
|
+
- `scope: codebase` in frontmatter.
|
|
162
|
+
- omit `## Source Material`, `## Problem / Symptom`.
|
|
163
|
+
- keep `## Scan Scope`, `## Priority Lenses`.
|
|
164
164
|
|
|
165
|
-
|
|
165
|
+
Do not fabricate empty sections. When there is no value, use `_(none)_`.
|
|
166
166
|
|
|
167
167
|
## frontmatter key
|
|
168
168
|
|
|
169
|
-
|
|
169
|
+
Every brief carries the following keys. The key set is checked by `validate-brief.py`.
|
|
170
170
|
|
|
171
171
|
- `type`
|
|
172
172
|
- `brief-id`
|
|
@@ -179,42 +179,42 @@ Codebase scan:
|
|
|
179
179
|
- `generator`
|
|
180
180
|
- `reporter-confirmations`
|
|
181
181
|
|
|
182
|
-
`brief-id
|
|
182
|
+
`brief-id` must equal the filename stem. At depth 0 the `parent-id` is `self`; a descendant's `parent-id` is its direct parent's `brief-id`.
|
|
183
183
|
|
|
184
184
|
## Recommended next phase
|
|
185
185
|
|
|
186
|
-
|
|
186
|
+
Write it into the `Recommended next phase:` of the brief body's top blockquote.
|
|
187
187
|
|
|
188
188
|
- observable error, repro, stack trace, error-zip record: `error-analysis`
|
|
189
|
-
- ambiguity
|
|
189
|
+
- a requirement with ambiguity or large Open Questions: `requirements-discovery`
|
|
190
190
|
- `scope: codebase`: `improvement-discovery`
|
|
191
|
-
-
|
|
191
|
+
- if ambiguous: `requirements-discovery`
|
|
192
192
|
|
|
193
|
-
`okstra-run
|
|
193
|
+
Do not auto-start `okstra-run`.
|
|
194
194
|
|
|
195
195
|
## Reporter Confirmations
|
|
196
196
|
|
|
197
|
-
`Open Questions
|
|
197
|
+
Collect the rows in `Open Questions` that only the reporter can answer.
|
|
198
198
|
|
|
199
199
|
- `intent-check:`
|
|
200
200
|
- `conversion-block:`
|
|
201
201
|
|
|
202
|
-
|
|
202
|
+
If a `[CONFIRMED <date> → RC-N]` marker already exists, exclude it from pending. Ask the user whether to answer now; if they answer, record it verbatim under `## Reporter Confirmations`. Do not delete the row — attach a marker.
|
|
203
203
|
|
|
204
|
-
|
|
204
|
+
At most 12 questions per run. If pending exceeds 12, ask only the top 12 in `conversion-block:` → `intent-check:` order, leave the rest as `partial`, then tell the user which rows remain.
|
|
205
205
|
|
|
206
|
-
|
|
206
|
+
Status values:
|
|
207
207
|
|
|
208
|
-
- `complete`: pending reporter-only
|
|
209
|
-
- `partial`:
|
|
210
|
-
- `skipped`:
|
|
211
|
-
- `pending`: handoff
|
|
208
|
+
- `complete`: all pending reporter-only rows are answered. The validator checks that every `intent-check:`/`conversion-block:` row has a `[CONFIRMED …]` marker.
|
|
209
|
+
- `partial`: only some are answered. The validator checks that at least one row has a `[CONFIRMED …]` marker (if nothing was received, `skipped`).
|
|
210
|
+
- `skipped`: the user chose to defer to a downstream phase.
|
|
211
|
+
- `pending`: treated as a pre-handoff state; do not proceed.
|
|
212
212
|
|
|
213
|
-
##
|
|
213
|
+
## Validation
|
|
214
214
|
|
|
215
|
-
|
|
215
|
+
After writing, run the validator before emitting the handoff message.
|
|
216
216
|
|
|
217
|
-
|
|
217
|
+
Installed copy:
|
|
218
218
|
|
|
219
219
|
```bash
|
|
220
220
|
~/.okstra/lib/validators/validate-brief.sh "<PROJECT_ROOT>/.okstra/briefs" --briefs-root "<PROJECT_ROOT>/.okstra/briefs"
|
|
@@ -226,19 +226,19 @@ repo checkout:
|
|
|
226
226
|
validators/validate-brief.sh "<PROJECT_ROOT>/.okstra/briefs" --briefs-root "<PROJECT_ROOT>/.okstra/briefs"
|
|
227
227
|
```
|
|
228
228
|
|
|
229
|
-
|
|
230
|
-
|
|
229
|
+
On failure, fix the cited brief and re-run. Fall back to a manual checklist only when the validator is absent.
|
|
230
|
+
When a `Related Task Graph` is present, the validator also checks the table header, relation enum, direction enum, and directed/undirected mismatch.
|
|
231
231
|
|
|
232
|
-
##
|
|
232
|
+
## Completion message
|
|
233
233
|
|
|
234
|
-
|
|
234
|
+
Single brief:
|
|
235
235
|
|
|
236
236
|
```text
|
|
237
237
|
brief saved: <abs-path>
|
|
238
238
|
next: /okstra-run (recommended task-type: <phase>)
|
|
239
239
|
```
|
|
240
240
|
|
|
241
|
-
|
|
241
|
+
Multi-brief:
|
|
242
242
|
|
|
243
243
|
```text
|
|
244
244
|
briefs saved (N):
|
|
@@ -247,12 +247,12 @@ briefs saved (N):
|
|
|
247
247
|
next: /okstra-run
|
|
248
248
|
```
|
|
249
249
|
|
|
250
|
-
##
|
|
250
|
+
## Forbidden patterns
|
|
251
251
|
|
|
252
|
-
- Source Material
|
|
253
|
-
- tracker/URL
|
|
254
|
-
- unlabelled augmentation
|
|
255
|
-
- `intent-inference
|
|
256
|
-
-
|
|
257
|
-
-
|
|
258
|
-
-
|
|
252
|
+
- Summarizing or tidying Source Material before inserting it.
|
|
253
|
+
- Guessing tracker/URL content without tool verification.
|
|
254
|
+
- Writing unlabelled augmentation.
|
|
255
|
+
- Leaving `intent-inference` without `intent-check:`.
|
|
256
|
+
- Writing a decision file into external docs/ADR. okstra decisions belong only in `<PROJECT_ROOT>/.okstra/decisions/`.
|
|
257
|
+
- Silently overwriting an entire child tree.
|
|
258
|
+
- Auto-starting `okstra-run` right after brief generation.
|