coding-os 0.3.2__py3-none-any.whl

core/commands/board.md

@@ -0,0 +1,27 @@
+Show the current Scrumban board state, grouped by swimlane × status.
+
+Steps:
+1. Call `cos_task_board` (no args → entire board; with `$ARGUMENTS` interpreted as swimlane → filter).
+2. Group cards by `swimlane` then by `status` (`icebox | in_progress | testing | blocked | complete`).
+3. Render the table below. Cap displayed cards per cell at 5 — link to `cos_task_search` for more.
+4. Surface WIP cap violations at the top (red flag).
+5. Surface tasks that have been in `in_progress` > 3 days at the bottom (stale alert per [task-driver](../skills/task-driver/SKILL.md) escalation ladder).
+
+Template:
+```markdown
+## Board — YYYY-MM-DD
+
+### WIP status
+| Lane | in_progress | testing | violations |
+|---|---|---|---|
+
+### {swimlane}
+| icebox | in_progress | testing | blocked |
+|---|---|---|---|
+| [TASK-NNN] title | ... | ... | ... |
+
+### Stale (in_progress > 3 days)
+- [TASK-NNN] {title} — in_progress since {date} ({N} days)
+```
+
+For interactive browsing the human can run `cos board --web` (opens Hub UI at http://127.0.0.1:9188). Mention this as the visual alternative if the user is exploring a complex state.

core/commands/classify.md

@@ -0,0 +1,23 @@
+Record the Complexity Gate (Cynefin × dimensions) for the current task before any code edit.
+
+The Complexity Gate is mandatory per [Rule 7](../../docs/governance/critical-rules.md) and [core/rules/thinking_os.md](../rules/thinking_os.md). It tells future hooks + reviewers what cognitive depth this task warrants. Skip → `enforce-skill.sh` may block edits on COMPLICATED+ paths.
+
+Steps:
+1. If `$ARGUMENTS` is provided in the form `Q1 Q2` (e.g. `COMPLICATED 3`), use it directly. Otherwise infer from the conversation:
+   - **Q1 (Cynefin):** `CLEAR` (known fix) | `COMPLICATED` (known type, needs design) | `COMPLEX` (unknown answer, needs experiment) | `CHAOTIC` (broken now, act first) | `CONFUSION` (decompose first).
+   - **Q2 (dimensions):** integer count of distinct concerns this task touches (auth + DB + UI = 3).
+2. State your classification + one-sentence rationale.
+3. Persist via the canonical gate writer — `write-state.sh` (the same hook the kernel rule's Record Gate documents). Replace `.claude` / `claude` with your adapter dir (`.codex` / `codex` for Codex):
+   ```
+   bash .claude/hooks/write-state.sh .coding-os/claude/.thinking_os-gate "<Q1> <Q2>"
+   ```
+   This writes `$COS_AGENT_DIR/.thinking_os-gate` and unblocks downstream skill/edit hooks.
+4. If `Q1` is `COMPLICATED` or `COMPLEX`, invoke `Skill thinking_os` for the full Zoom cycle.
+5. If `Q1` is `CHAOTIC`, treat as an incident — load `Skill incident-response`, stabilize first.
+
+Output format:
+```
+Classification: <Q1> <Q2>
+Rationale: <one sentence>
+Next step: <Plan | Zoom cycle | Incident stabilization>
+```

core/commands/compose.md

@@ -0,0 +1,23 @@
+Compose the 11-semantic-role chain for the current COMPLICATED+ task and dispatch.
+
+Use when the thinking_os gate is `COMPLICATED` or `COMPLEX` (Q1) — the chain orchestrates researcher → analyst → architect → … → reviewer/observer per the formula composer at [src/core/thinking_os/formula_composer.py](../thinking_os/formula_composer.py). For `CLEAR` tasks skip; the composer is intentionally heavyweight.
+
+Steps:
+1. Read the active task id (`$COS_AGENT_DIR/.task-current`) and current gate (`$COS_AGENT_DIR/.thinking_os-gate`). If `$ARGUMENTS` is provided as `TASK-NNN`, use it directly.
+2. Invoke `cos_compose_chain(task_id="<TASK-ID>")` (the MCP tool registered in [src/core/thinking_os/tools/cognition.py](../thinking_os/tools/cognition.py)). The envelope returns:
+   - `data.chain`: ordered `RoleActivation` list (role · intensity · formula).
+   - `data.signals`: the `TaskSignals` the composer extracted (complexity · domain · risk markers).
+3. State the chain inline so the user sees the orchestration: `🧠 chain: researcher → analyst → … → reviewer`.
+4. Execute the chain — either by dispatching each role via `cos_dispatch_formula_run` (Claude SDK extra installed) or by walking the formulas inline (no SDK extra). Each role's `EvidenceBundle` is recorded via `cos_supervise_record_output`.
+5. Update the task's Work Log with `chain composed: <role list>`.
+
+Acceptance gates:
+- Skipping `cos_compose_chain` on a COMPLICATED+ task is a known dead-path: a prompt-based nudge that agents read but don't act on. `/compose` is the deterministic alternative: one keystroke, one tool call, one chain.
+- The chain output is persistent — `formula_dispatches` and `persona_selections` tables grow by ≥1 row per `/compose` invocation.
+
+Output format:
+```
+🧠 chain: <r1> → <r2> → … → <rN>     (complexity=<Q1>, dimensions=<Q2>)
+   signals: <domain>, <risk-markers>
+   formulas: <preset-id> · <preset-id> …
+```

core/commands/daily.md

@@ -0,0 +1,31 @@
+Run the Scrumban daily standup view and present a structured summary.
+
+Steps:
+1. Call MCP tool `cos_task_daily` (canonical source — already aggregates yesterday / today / blocked / WIP / streak).
+2. Render in the template below (matches `task-driver` skill conventions). Use information ONLY from the tool envelope — do not fabricate task IDs or titles.
+3. End with the next-action recommendation: which task should be picked up next, based on `cos_task_pick`.
+
+Template:
+```markdown
+## Daily — YYYY-MM-DD
+
+### Yesterday
+- [TASK-NNN] {title} → moved to {status}, {one-line outcome}
+
+### Today (candidates)
+- [TASK-NNN] {title} ({swimlane}/{kind}, priority {P})
+
+### Blocked
+- [TASK-NNN] {title} — blocker: {reason}, since {date}
+
+### WIP check
+- in_progress: {n}/cap{cap}
+- testing: {n}/cap{cap}
+- violations: {none | list}
+
+### Recommended next: TASK-NNN — {one-line reason}
+```
+
+If `cos_task_daily` returns empty (no tasks ever created), explain that the board is empty and offer to create a task via `cos_task_create`.
+
+ADHD-friendly default: silent on broken streaks (per [task-driver](../skills/task-driver/SKILL.md) "Daily streak ≠ shame"). Only surface if the user asks.

core/commands/diagnose.md

@@ -0,0 +1,7 @@
+Run system health diagnostics and interpret the results.
+
+Steps:
+1. Run `cos doctor` — deep health check (scaffold, DB schema, adapter, symlinks). Use `cos health` for a fast summary if `doctor` is too slow.
+2. For each FAIL item: explain what's wrong and give the exact fix command
+3. For each WARN item: explain if it matters for the current environment
+4. Summarize: what's healthy, what needs attention, and prioritized fix order

core/commands/memory-search.md

@@ -0,0 +1,23 @@
+Search agent memory + learned patterns for cross-session context relevant to $ARGUMENTS.
+
+Use during the **Orient** phase of the Core Loop ([../skills/thinking_os/SKILL.md](../skills/thinking_os/SKILL.md)) — never as a substitute for reading current code, only as a prefetch for "have I solved this before?".
+
+Steps:
+1. If `$ARGUMENTS` is empty, ask the user what to search for.
+2. Call `cos_search(query=$ARGUMENTS, min_confidence=0.3, since_days=180, limit=10)`.
+3. If 0 hits: try `cos_doc_search(query=$ARGUMENTS, limit=5)` (escalate to docs layer per [../rules/memory.md](../rules/memory.md) routing).
+4. If still 0 hits: tell the user "no prior context — this looks new" and suggest a fresh `Skill thinking_os` Cynefin classification.
+5. If hits exist, render:
+   ```markdown
+   ## Memory search — "{query}"
+
+   ### Top patterns ({n})
+   1. [{confidence}] {title}
+      Type: {memory_type} | Impact: {impact_score} | Last seen: {date}
+      Summary: {short}
+      Source: {cos_details tool call to fetch full body}
+   ```
+6. For each hit ≥ 0.7 confidence: offer to invoke `cos_details(id=...)` to expand.
+7. **Verify before recommending** (per [../rules/memory.md](../rules/memory.md)): if a high-confidence pattern names a file or function, confirm it still exists in the repo before quoting it as authoritative.
+
+Memory-hygiene reminder: this is a **read** operation. If during the work you confirm a pattern was useful, record back via `cos_observation_record` so the next session benefits.

core/commands/new-project.md

@@ -0,0 +1,33 @@
+Scaffold a new coding-os project non-interactively — the official agent recipe (TASK-359).
+
+Steps:
+1. Discover what's available (read-only):
+   - `cos list-stacks --format json` → stacks (grouped by `language`) + `presets`.
+   - `cos skills-list --stack <id> --format json` → required/recommended/optional skills for a stack.
+2. Preview the composition BEFORE writing anything:
+   - `cos init --preset <id> --dry-config` (or `--template a --template b --dry-config`)
+   - Read the swimlane union and the reported merge conflicts (later stack wins). Nothing is written.
+3. Create in one shot (every Composer option has a flag — full parity, incl. multi-agent + module toggles):
+
+```bash
+cos init \
+  --agent claude \                   # one+ adapters, comma-separated: --agent claude,codex
+  --preset nextjs-fastapi \          # OR: --template go-fiber --template fastapi
+  --name my-app -d /path/to/parent \ # omit --name only in interactive shells
+  --skills redis,docker \            # extra core skills (validated; see cos skills-list)
+  --profile standard \               # module surface: lite | core | standard (default) | full
+  --disable-module memory \          # optional, repeatable: turn a subsystem off at create
+  --summary "One to two paragraphs describing the product, its users, and what matters most." \
+  --yes --no-index
+```
+
+4. Verify: exit code 0; `--format json` emits the summary object (`path`, `slug`, `agents`, `templates`, …). The project self-registers in the hub; `--summary` seeds `docs/_meta/project-description.md` (the description→PRD intake) and leaves `_TODO:` markers in the seeded PRD, so the panel still offers the guided interview.
+
+Rules:
+- Non-TTY without `--yes` fails fast naming the missing flags — never rely on prompts in automation.
+- `--preset` and `--template` are mutually exclusive; unknown skills/stacks/presets exit 2 listing what exists.
+- `--agent` takes one or more adapters (`claude`, `codex`), comma-separated — a project may host several.
+- `--profile <name>` picks the module surface (`cos init --help` lists the live set from `subsystems.yaml`): `lite` = kernel only (discipline + safety, near-zero MCP tools — the MCP-averse adopter), `core`, `standard` (default: `cognition` + `cicd` off), `full` = everything. Omitting it applies the registry default, so a project can end up leaner than you expected — pass it explicitly when the surface matters.
+- `--disable-module <id>` (repeatable) turns one subsystem off; ids come from `subsystems.yaml` (`docs`, `tasks`, `graph`, `memory`, `cognition`, `observability`, `hub-extras`, `cicd`). `kernel` can't be disabled and a module's dependents go with it (unknown/kernel exit 2).
+- **Profile and `--disable-module` are UNIONED** — a profile can only ever remove more. `--enable-module <id>` (repeatable) is the escape: it force-enables a module after the union, pulls its `depends_on` chain in with it, and errors when the same id is also explicitly disabled; that is exactly what the Hub Composer sends for chips left on. `cos module list` shows the result.
+- Don't pass `--name` you can't validate: `^[a-z0-9][a-z0-9._-]{0,63}$`.

core/commands/retro.md

@@ -0,0 +1,38 @@
+Run a Scrumban retrospective for the period specified by $ARGUMENTS (default: 14 days).
+
+Steps:
+1. Resolve period: if `$ARGUMENTS` is a number → days; if `$ARGUMENTS` is `week|month|quarter` → 7|30|90 days; if empty → 14 days.
+2. Call MCP tool `cos_task_retro(since="Nd")` (canonical aggregation of completed + blocked + failure patterns; `since` is a duration string like "14d").
+3. Call `cos_failure_pattern_query(limit=20)` to surface recurring failure modes (frequency-ranked `root_cause` categories from `backtrack_events`; treat count ≥ 2 as recurring — filter client-side).
+4. Call `cos_metric_trend(metric="time_to_solution", window_days=N)` to detect process drift.
+5. Read `$COS_PANEL_DIR/.clear1-bypass-log` (if present): each line is a self-issued `CLEAR 1` enforcement-bypass plus its justification. Report the count + justifications — a rising count means the discipline is being routed around, not internalized.
+6. Promotion candidates: call `cos_learn_suggest(limit=20)` and filter client-side to **Trusted, not yet promoted** lessons (`confidence ≥ 0.7 AND times_validated ≥ 3`; suggest already excludes promoted rows). For each candidate propose a destination (an existing rule file section, or a skill) and show the draft from `cos_promote(pattern_id, target)` — **apply NOTHING without explicit user approval**. On approval, write the returned content to the agreed destination (governance edit — needs the task marker); the tool already stamped `promoted_to`, which removes the row from digest/suggest.
+7. Render in the template below. The action items are the only place the agent should *propose* content beyond the data — every line needs an owner placeholder + due-date placeholder (the user fills them in).
+
+Template:
+```markdown
+## Retro — YYYY-MM-DD (period: {N} days)
+
+### What shipped ({count})
+- [TASK-NNN] {title} → complete, {date}
+
+### What broke / blocked ({count})
+- [TASK-NNN] {title} — blocked for {days}; root cause: {category}
+
+### Patterns (from cos_failure_pattern_query)
+- {recurring category}: {N occurrences}; suggested mitigation: {action}
+
+### Trend (time_to_solution)
+- median {Nm} (vs {Nm} previous period) — {improving | stable | regressing}
+
+### Self-issued CLEAR-1 bypasses ({count})
+- {justification} — what discipline was skipped, and was it warranted
+
+### Promotion candidates (Trusted lessons → durable rules; {count})
+- [#{pattern_id}] {lesson one-liner} — validated {N}×; proposed destination: {rule/skill path} — approve?
+
+### Action items
+- [ ] {action} — @owner — due YYYY-MM-DD
+```
+
+No-blame rule (per [incident-response](../skills/incident-response/SKILL.md)): describe the failing system, never the person.

core/commands/review.md

@@ -0,0 +1,14 @@
+Review the current changes against project coding standards.
+
+Steps:
+1. Run `git diff --name-only` to see which files changed
+2. For each changed file, check against the relevant engineering rules
+3. Run the appropriate verification commands
+4. Report findings in this format:
+
+```
+file:line — severity (critical/warning/info) — issue — suggested fix
+```
+
+Focus on: bugs, security issues, missing error handling, missing tests.
+Skip: style preferences, minor formatting, local patterns that work.

core/commands/task.md

@@ -0,0 +1,17 @@
+Load and summarize the task specified by $ARGUMENTS.
+
+Steps:
+1. Run `cos task-show $ARGUMENTS` (or read the task detail file directly from docs/tasks/)
+2. Read the full task detail file — including Notes and Session Checkpoint sections
+3. Classify the task domain and identify which playbook applies
+4. Present a summary:
+   - **Goal:** why this task exists (1-2 sentences)
+   - **Domain:** which playbook route
+   - **Scope:** Small / Medium / Large (based on file count and complexity)
+   - **Requirements:** the Given/When/Then acceptance criteria
+   - **Dependencies:** any prerequisite tasks and their status
+   - **Verification:** what commands to run when done
+   - **Session Checkpoint:** any previous progress (if exists)
+5. Ask: "What would you like to do? (a) Start — run Classify → Orient → Plan → Execute, (b) Investigate first, (c) Mark as blocked"
+
+If no task number is provided, run `cos task-pick` to suggest the next task.

core/commands/verify.md

@@ -0,0 +1,34 @@
+Run the matrix-targeted verification commands for files that have changed in the current task.
+
+Per [../rules/test-discipline.md](../rules/test-discipline.md): never `pytest tests/ -q` mid-task (6 min full sweep). Only run the matrix command(s) tied to changed files.
+
+Steps:
+1. Determine the change scope:
+   - If `$ARGUMENTS` is provided (file paths), use them.
+   - Otherwise run `git diff --name-only` + `git status --porcelain` to gather changed files.
+2. Map each changed path to its matrix row (from [AGENTS.md](../../AGENTS.md) §Verification Matrix). Surface conflicts: if a file matches no row, ask the user before guessing.
+3. Build the deduped list of commands to run.
+4. State the plan: "I will run: <commands>". Show it before executing — gives the user a chance to redirect.
+5. Run each command. Stream output. Stop at first FAIL with the failing line surfaced.
+6. On success: append a short work-log note via `cos_work_log_append(task_id=<current>, summary=<one line>)`.
+7. On failure: do NOT mark the task `complete`. Suggest: keep in `testing`, fix the failure, re-run.
+
+When a full sweep IS allowed (state it out loud first — per [test-discipline.md](../rules/test-discipline.md)):
+- Pre-merge final gate.
+- Cross-cutting refactor touching ≥3 matrix rows.
+- User explicitly asked "run all tests".
+
+Output format:
+```markdown
+## Verification — {N} command(s)
+
+### Plan
+- {file pattern} → `{command}`
+
+### Results
+- ✅ `{command}` — {duration}
+- ❌ `{command}` — {failure summary}, see {line}
+
+### Next step
+{recommendation}
+```