cowork-flow 0.0.37 → 0.0.39

package/template/skills/party-mode/SKILL.md

@@ -1,151 +1,80 @@
 ---
 name: party-mode
-description: Use when the user manually requests Party Mode or a real multi-agent roundtable for advisory discussion, option review, risk review, or decision convergence.
+description: Use when the user manually requests Party Mode or a runtime-controlled multi-agent board discussion where children communicate through board APIs and the moderator only monitors or corrects drift.
 ---
 
 # Party Mode
 
-Use this skill as a manual advisory roundtable. Coordinate true child agents, not simulated personas, through the current Host Adapter.
+Use this skill as the single public Party Mode entrypoint.
 
-**Related:** [Party Mode V2](../party-mode-v2/SKILL.md) -- runtime-controlled board discussion where children communicate through board APIs and the moderator only monitors or corrects drift.
+The Python runtime is the source of truth for discussion state, board
+visibility, validation, round limits, and final reports. The runtime board owns
+child-visible discussion state.
 
 ## Boundaries
 
 See [SHARED-BOUNDARIES.md](SHARED-BOUNDARIES.md) for common boundaries and advisory limits.
 
-- Generic `worker`, `default`, or `explorer` agents may provide advisory views, but their output never proves implementation or checking done.
+- Party Mode is advisory only. It does not satisfy formal Implement or Check.
+- The moderator does not forward, summarize, rewrite, or synthesize child opinions for other child agents.
 
-## Defaults And Config
+## Runtime First
 
-Built-in defaults:
-
-- `max_agents=3`
-- `max_rounds=5`
-
-These defaults are configurable values, not hard-coded constants. Effective config order:
+Always use the runtime controller:
 
 ```text
-call arguments > task/change config > `.cowork-flow/config.yaml` > skill defaults
+.cowork-flow/run party-v2 init
+.cowork-flow/run party-v2 monitor
+.cowork-flow/run party-v2 view
+.cowork-flow/run party-v2 post
+.cowork-flow/run party-v2 respond
+.cowork-flow/run party-v2 advance
+.cowork-flow/run party-v2 record-action-result
+.cowork-flow/run party-v2 finalize
 ```
 
-Configurable fields:
-
-- `max_agents`
-- `max_rounds`
-- agent roster or review lenses
-- report enabled
-- report path
-- round phase policy, including when challenge may continue and when convergence must begin
-
-Safety gates:
-
-- continue conditions can be tightened but not removed
-- stop conditions can be tightened but not removed
-- schema core fields can be extended but not removed
-- exceeding effective limits requires explicit user approval
-
-## Round Model
-
-1. Frame the question, decision needed, scope, and evidence packet.
-2. Select the smallest useful agent roster or review lenses within effective `max_agents`. Record why each selected voice is useful and why omitted voices are not needed.
-3. Round 1 uses fresh child contexts. Send each child the same packet and one lens. Child agents cannot see each other.
-4. Synthesize evidence-backed positions into a compact claim table: `claim_id`, owner, claim, evidence, counterclaim, evidence gap, and decision impact.
-5. Continue only when a continue condition is met. Send narrow follow-up prompts to the smallest useful set of children, and bind each prompt to one `claim_id`.
-6. Follow-up rounds should prefer the same live child that produced or challenged the relevant position. Send only the target claim, counterclaim, evidence gap, and ask the child to `agree`, `reject`, or `revise`.
-7. For Challenge rounds, the default stance is scrutiny. Test the opposing claim first; choose `agree` only after naming the evidence that compels agreement.
-8. Spawn an extra child only when the effective roster or lens config allows it, a live child failed, or the user approves expansion.
-9. Stop when any stop condition is met and no dispatched child is still running. Then close live children through the Host Adapter close primitive.
-
-Round intent:
-
-- Opening round: independent first judgments.
-- Challenge rounds: rebuttal, risk drilldown, or evidence repair on specific disagreements.
-- Convergence rounds: decision check only. Verify, narrow, or choose. Do not open new directions.
-
-Default mapping:
-
-- Round 1 = Opening.
-- Round 2+ = Challenge while continue conditions still expose material disagreement, material risk, missing evidence, or untestable acceptance criteria.
-- Convergence begins when the coordinator can write one recommended direction and no material challenge condition remains.
+Do not bypass a runtime rejection by manually accepting child output. Runtime
+validation failures must be fixed by a corrected child submission or by ending
+the discussion.
 
-After convergence begins, do not reopen exploration unless the user approves or new concrete evidence appears.
+## Board Rules
 
-## Continue Conditions
+- Child agents communicate through the board API.
+- Child-visible board output must be current-round only.
+- Historical board state is runtime-private and may be used only for audit or final reports.
+- Use at least three child agents unless the effective runtime config explicitly allows a different value.
+- The runtime emits host-neutral next actions. The active Host Adapter or moderator executes them for Codex, Claude Code, or OpenCode.
+- Host action results must be recorded back through `record-action-result` so `agents.json`, audit logs, and action history can prove lifecycle state.
 
-Run another round only if at least one condition holds:
+## Child Response Rules
 
-- A disagreement could change the recommended decision.
-- A high risk lacks enough evidence.
-- Acceptance criteria are still not testable.
-- A child found new file, command, rule, or user-scenario evidence.
-- The coordinator cannot write one recommended direction.
-
-## Stop Conditions
-
-Stop when any condition holds:
-
-- Recommendation, rejected options, and measurable acceptance criteria are clear.
-- Remaining issue is user value preference, not missing evidence.
-- A full round adds no evidence and does not narrow scope.
-- Effective `max_rounds` is reached.
-- Output fails schema, and one repair prompt does not fix it.
-
-## Waiting Children
-
-- A wait timeout is not a child timeout.
-- If a child remains live after a wait timeout, wait again or report it in `pending_children`.
-- Do not close, cancel, omit, or synthesize around a live child unless the user explicitly asks to close it.
-- When the discussion has converged or the user ends it, close live children after their final output is recorded.
-
-## Child Output Schema
-
-Each child must return these core fields. Extra fields are allowed only after them.
+When a child sees a different position, it must choose exactly one:
 
 ```text
-position:
-evidence:
-risk:
-tradeoff:
-rejected_option:
-acceptance_signal:
-what_would_change_my_mind:
+maintain
+revise
+concede
 ```
 
-Follow-up rounds may add these fields after the core fields:
+`concede` requires accepted evidence and why the prior position failed.
+`revise` requires the accepted part, rejected part, and updated position.
+`maintain` requires counter evidence or counter reasoning.
 
-```text
-claim_id:
-responding_to:
-opposing_claim:
-position_delta:
-evidence_delta:
-still_disagree:
-```
+Unsupported agreement, vague revision, and evidence-free rebuttal are invalid.
 
-Use `position_delta` to say whether the child maintained, narrowed, or changed its position.
-Reject unsupported opinion. Evidence should name files, commands, rules, observed behavior, user scenarios, or concrete assumptions.
+## Moderator Role
 
-## Coordinator Output Schema
+The moderator may:
 
-Final synthesis must return these core fields. Extra fields are allowed only after them.
+- run runtime commands,
+- execute host-neutral next actions through the active host,
+- record off-topic warnings through the runtime,
+- close children only when the runtime asks for closeout,
+- show runtime status or final reports to the user.
 
-```text
-effective_max_agents:
-effective_max_rounds:
-rounds_used:
-selected_agents:
-claim_table:
-agent_turns:
-pending_children:
-consensus:
-disagreements:
-evidence:
-decision:
-rejected_options:
-acceptance_criteria:
-open_questions:
-early_stop_reason:
-stop_reason:
-```
+The moderator must not:
 
-`selected_agents` must include the selected agent or lens names and selection reasons. `agent_turns` should preserve a compact transcript with round, agent or lens, `claim_id`, position, and `position_delta`. Keep the final decision traceable to child evidence. Do not count votes as validation.
+- forward one child opinion to another child,
+- create a claim table for child prompts,
+- vote-count as validation,
+- decide which child is correct.

package/template/.cowork-flow/scripts/common/gates/spec_validator.py

@@ -1,53 +0,0 @@
-#!/usr/bin/env python3
-"""Spec markdown section validator for cowork-flow."""
-
-from __future__ import annotations
-
-import re
-from pathlib import Path
-
-SECTION_CONFIG: dict[str, tuple[str, ...]] = {
-    "contract": ("Goal", "When to Use", "Rules", "Examples"),
-    "skill": ("Overview", "When to Use", "Steps", "Verification"),
-    "guide": ("Goal", "When to Use", "Process", "Anti-Rationalization"),
-    "default": ("Goal", "Rules"),
-}
-
-HEADER_RE = re.compile(r"^##\s+(.+)$", re.MULTILINE)
-
-
-def validate_sections(file_path: Path | str, spec_type: str = "default") -> tuple[bool, list[str]]:
-    """Validate a spec markdown file has all required sections.
-
-    Returns (is_valid, error_messages).
-    """
-    path = Path(file_path)
-    errors: list[str] = []
-
-    if not path.is_file():
-        return False, [f"File not found: {path}"]
-
-    content = path.read_text(encoding="utf-8").strip()
-    if not content:
-        return False, ["File is empty"]
-
-    required = SECTION_CONFIG.get(spec_type)
-    if required is None:
-        return False, [f"Unknown spec type: {spec_type}"]
-
-    matches = list(HEADER_RE.finditer(content))
-    found: dict[str, str] = {}
-    for i, m in enumerate(matches):
-        name = m.group(1).strip()
-        start = m.end()
-        end = matches[i + 1].start() if i + 1 < len(matches) else len(content)
-        body = content[start:end].strip()
-        found[name] = body
-
-    for req in required:
-        if req not in found:
-            errors.append(f"Missing: {req}")
-        elif not found[req]:
-            errors.append(f"Empty: {req}")
-
-    return (not errors, errors)

package/template/.cowork-flow/scripts/common/gates/validate_jsonl.py

@@ -1,32 +0,0 @@
-#!/usr/bin/env python3
-"""JSONL file format validator for cowork-flow context files."""
-
-from __future__ import annotations
-
-import json
-from pathlib import Path
-
-
-def validate_format(file_path: Path | str) -> tuple[bool, list[str]]:
-    """Validate a JSONL file and return (is_valid, error_messages)."""
-    path = Path(file_path)
-    errors: list[str] = []
-
-    try:
-        content = path.read_text(encoding="utf-8").strip()
-    except (OSError, UnicodeDecodeError) as exc:
-        return False, [f"Cannot read file: {exc}"]
-
-    if not content:
-        return False, ["File is empty"]
-
-    for line_no, raw_line in enumerate(content.splitlines(), start=1):
-        line = raw_line.strip()
-        if not line:
-            continue
-        try:
-            json.loads(line)
-        except json.JSONDecodeError as exc:
-            errors.append(f"Line {line_no}: Invalid JSON: {exc}")
-
-    return (not errors, errors)

package/template/skills/before-dev/SKILL.md

@@ -1,41 +0,0 @@
----
-name: before-dev
-description: MANDATORY GATE — call before ANY code change, file edit, or subagent dispatch. Checks workflow state and either allows or blocks the action.
----
-
-# Before Dev — Pre-Development Workflow Gate
-
-MUST invoke before any file edit, code change, or subagent dispatch. Reads the current `<workflow-state>` block and decides: allow or block.
-
-This skill is NOT a checklist or context loader — it is a gate. Do not proceed to code changes without passing through this gate.
-
-**Exemptions**: read-only Q&A, pure query commands (`git status`, `task next`, `task current`), user explicitly says "just make the change, skip the workflow".
-
----
-
-## Step 1: Read Workflow State
-
-Read the `<workflow-state>` block (Status, Source). If absent, check for `cowork_runtime_context_id` in the user prompt:
-- **Has it** → subagent without injected state. Skip directly to the `delegated_subtask` branch below.
-- **No `cowork_runtime_context_id`** → no context identity. Fail-closed: block and direct the user to `task start` or `continue`.
-
-## Step 2: Act by Status
-
-| Status | Action |
-|--------|--------|
-| `no_task` | BLOCK. Direct to `brainstorming` / `writing-plans` / `continue`. Allow read-only Q&A. |
-| `delegated_subtask` | Execute. `subagent bind <id> <key>`, load task dir, complete leaf work. No start/resume/commit. |
-| `planning` | BLOCK implementation. Allow planning files only (`decision-anchor.md`, `*.jsonl`). |
-| `in_progress` | ALLOW. Load context (below). L2 tasks require `doubt-review` before implementing. |
-| `review` | Verify with `cowork-check`. Minor fixes only — no new implementation. |
-| `completed` | BLOCK. Create a new task via `task archive` → `task create`. |
-
-### Context loading for `in_progress`
-
-1. Read `<task>/decision-anchor.md` (goals, scope, acceptance criteria).
-2. Read `<task>/implement.jsonl` + plan steps (from `<task>/task.json` relatedFiles or `.cowork-flow/plans/`).
-3. Confirm success criteria, files involved, and verification commands. Begin implementation.
-
----
-
-**Fail-closed fallback**: if `<workflow-state>` is absent AND no `cowork_runtime_context_id` is present, block all changes and direct to `task start` or `continue`. Abnormal statuses (`stale`, `unknown`, or unrecognized) are treated the same — run `resume` first.

package/template/skills/check/SKILL.md

@@ -1,53 +0,0 @@
----
-name: check
-description: Use after code or workflow changes to verify quality, spec compliance, tests, cross-layer contracts, and template/root consistency before finish-work.
----
-
-# Check
-
-Use this after implementation and before `finish-work`.
-
-Apply ERROR_OUTPUT_AS_DATA contract. If tempted to skip steps, re-execute with verifiable evidence.
-
-## Steps
-
-1. Read active task decision-anchor.md, plan, and `check.jsonl`.
-2. Review `git diff --name-only` and `git diff`.
-3. Check contracts across caller/callee, command output, persisted state, templates, and docs.
-4. Verify spec compliance:
-   - Read each spec file listed in `check.jsonl`.
-   - For each guideline in the spec, check the diff for violations (naming, structure, encoding, error handling, quality gates).
-   - Spec files not listed in `check.jsonl` do not apply to this check.
-5. Verify all new/modified code against project coding standards:
-   - For every source file added or changed in the diff, determine whether it is backend or frontend.
-   - Read the matching index (`.cowork-flow/spec/backend/index.md` or `.cowork-flow/spec/frontend/index.md`) to discover which guideline files apply.
-   - Read each applicable guideline file and cross-check the changed code for violations (UTF-8 enforcement, directory structure, error handling, layering, component patterns, etc.).
-   - Report each violation with: file path, violated rule, and a one-line fix suggestion.
-6. Confirm `.cowork-flow/spec/` is updated or explicitly unchanged.
-7. Review test intent: reject shallow tests that do not fail for meaningful behavior breaks.
-8. Run focused tests that would fail if the changed behavior broke.
-9. Run broader validation when the change touches shared runtime, templates, packaging, or public workflow.
-10. Report `test_intent_review` with the key tests that defend decision-anchor.md acceptance behavior.
-11. Report spec compliance: for each spec/ file checked, state pass/fail with evidence from the diff.
-
-## Report
-
-Return:
-
-- Issues found and fixes made.
-- Files reviewed.
-- Commands run and results.
-- Remaining risks.
-
-Do not claim success from intent. Use command output and reviewed diffs as evidence.
-
-## Debug Quality Check
-
-- Root cause fix has a corresponding regression test (not a symptom fix)
-- Not a symptom fix (fixed UI-level duplication instead of API-level duplication)
-- Evidence recorded in `<task>/debug.jsonl` (if applicable)
-- If a repeatedly triggered bug, break-loop record is in `<task>/break-loop.md`
-
-## Simplification Review
-
-See [simplification-guide.md](./simplification-guide.md) when refactoring > 50 lines.

package/template/skills/check/simplification-guide.md

@@ -1,47 +0,0 @@
-# Simplification Review
-
-Run when code changes exceed 50 lines or review finds readability issues.
-
-## Pre-Simplification Self-Check (Chesterton's Fence)
-
-For each simplification, answer:
-- What is this code's responsibility? Who calls it? What does it call?
-- Will existing tests' defined behavior be broken?
-- Why did the original author write it this way? (check git blame)
-
-If you cannot answer, stop — you do not understand this code.
-
-## Simplification Signals
-
-| Signal | Action |
-|---|---|
-| Nesting depth >= 3 levels | Extract guard clause or helper |
-| Function > 50 lines | Split by responsibility into multiple named functions |
-| Nested ternary `a ? b : c ? d : e` | Replace with if/else / switch / lookup |
-| Boolean flag arguments `doThing(true, false, true)` | Replace with options object or split into two functions |
-| Same condition checked >= 3 times | Extract as a named predicate function |
-| Redundant wrapper `async () => await foo()` | Export foo directly |
-| Unused import / variable | Remove (after confirming no side effects) |
-| Missing type hint (when project convention requires it) | Add it |
-
-## Naming Readability Signals
-
-| Signal | Action |
-|---|---|
-| `data`, `result`, `temp`, `val` | Rename to describe content: `userProfile`, `errors` |
-| Abbreviations `usr`, `cfg`, `btn`, `evt` | Use full words (`id`, `url`, `api` are exceptions) |
-| Name contradicts behavior (`get` but mutates) | Rename to reflect actual behavior |
-| "What" comment (`// increment counter` on `count++`) | Remove comment |
-| "Why" comment (`// Retry because API is flaky`) | Keep |
-
-## Rule of 500
-
-If a refactoring would modify > 500 lines, use automated tools (sed/codemod/AST transform) rather than manual editing — manual large-scale changes are error-prone and cause review fatigue.
-
-## Red Flags
-
-- Simplification causes test failures (behavior was changed — violates "preserve behavior" principle)
-- "Simplification" results in longer and harder-to-read code
-- Renaming based on personal preference rather than project convention
-- Removing error handling "to make the code cleaner"
-- Batching multiple simplifications into one non-rollbackable large commit

package/template/skills/continue/SKILL.md

@@ -1,29 +0,0 @@
----
-name: continue
-description: Use when resuming an in-progress cowork-flow task after interruption, context compression, or a new session.
----
-
-# Continue
-
-Use this to recover the next actionable step without rereading the whole repository.
-
-## Steps
-
-1. Run `.cowork-flow/run resume` or `.\.cowork-flow\run.cmd resume` on Windows.
-2. Run `.cowork-flow/run task current`.
-3. Read the active task `decision-anchor.md`.
-4. Read the current plan only if the task references one.
-5. Read the relevant JSONL index for the current phase: `implement.jsonl`, `check.jsonl`, or `debug.jsonl`.
-6. Inspect `git status --short` and any changed files relevant to the task.
-
-## Output
-
-State:
-
-- Active task and phase.
-- Completed work.
-- Next step.
-- Blockers.
-- Verification still required.
-
-Avoid broad archive/history scans unless the active task explicitly depends on them.

package/template/skills/doubt-review/SKILL.md

@@ -1,118 +0,0 @@
----
-name: doubt-review
-description: Use when making non-trivial implementation decisions, starting L2 tasks, or claiming behavioral correctness. Use when correctness matters more than speed, working in unfamiliar code, or stakes are high.
----
-
-# Doubt Review
-
-## Overview
-
-Non-trivial decisions must pass doubt review before being allowed into implementation. This is not optional self-reflection — it is a sub-step of the before-dev gate for L2 tasks.
-
-Unlike `/review` (a verdict on a completed artifact), doubt-review is an in-flight posture: non-trivial decisions are cross-examined while course-correction is still cheap.
-
-## When to Apply
-
-Trigger conditions (any one applies):
-- L2 tasks (L1 optional but recommended)
-- Introducing or modifying branching logic
-- Crossing module boundaries
-- Relying on properties the type system cannot verify (thread safety, idempotency, ordering invariants)
-- When the user explicitly requests it
-
-Does not apply to:
-- Mechanical operations (renaming, formatting, file moves)
-- Reading/summarizing existing code
-- One-line changes where correctness is obvious
-- When the user explicitly requests speed over verification
-
-## The 5-Step Doubt Cycle
-
-### Step 1: CLAIM — a clear 2-3 line statement
-
-```
-CLAIM: "<one-sentence decision>"
-WHY THIS MATTERS: <why this decision being wrong would be fatal>
-```
-
-If you cannot write a CLAIM in 2-3 lines, you have a vague feeling, not a decision. The distance between feeling and decision is the research/thinking you need to do.
-
-### Step 2: EXTRACT — minimal reviewable unit
-
-- Code: diff or function (not an entire file)
-- Decision: 3-5 sentences + constraints
-- Strip reasoning — provide only the input, not the conclusion
-
-### Step 3: DOUBT — fresh-context adversarial review
-
-```
-Find problems with this artifact. Assume the author is overconfident. Look for:
-- Undeclared assumptions
-- Unhandled edge cases
-- Hidden coupling or shared state
-- Violated contract scenarios
-- Broken existing conventions
-- Failure modes under unexpected input
-
-Do not confirm. Do not summarize. Find problems, or explicitly state that no problems were found after review.
-
-ARTIFACT: <paste artifact>
-CONTRACT: <paste constraints>
-```
-
-**Critical**: pass only ARTIFACT + CONTRACT, not CLAIM. Including CLAIM biases the reviewer toward agreement.
-
-Note: you cannot spawn a fresh-context reviewer from within a subagent context. If you encounter a situation requiring doubt while inside a subagent, surface back to the main session.
-
-### Step 4: RECONCILE — classify each finding
-
-By priority (first matching category wins):
-1. CONTRACT misunderstanding → fix CONTRACT, then reclassify
-2. Valid + actionable → modify artifact, restart doubt cycle
-3. Valid but acceptable trade-off → record explicitly
-4. Noise → record and exclude
-
-### Step 5: STOP — bounded loop
-
-Stop when any condition is met:
-- Next round produces only trivial or already-considered findings
-- 3 cycles complete (stop; report to the user and do not proceed to a 4th)
-- User explicitly says "that's enough"
-
-Substantive findings remaining after 3 cycles = artifact is immature. Return to Step 2 to decompose.
-
-## Common Rationalizations
-
-| Excuse | Why It Fails | Better Approach |
-|---|---|---|
-| "I'm confident, skip doubt" | Confidence correlates poorly with correctness. Highest confidence is where blind spots hide. | Write a 2-line CLAIM and pass the artifact to fresh-context review. Confidence is not a gate. |
-| "Spawning a reviewer is expensive" | Debugging a bad commit in production costs more. The doubt cycle is bounded. | Run one doubt cycle now; a bounded 5-step loop costs far less than a production debug session. |
-| "Review will catch it at the review stage" | Review is the final gate. Doubt catches issues in-flight while course-correction is still cheap. | Catch it in-flight; run doubt-review before the artifact is committed or merged. |
-| "Doubting every step causes infinite delay" | Doubt only applies to non-trivial decisions. Re-read When NOT to Use. | Confirm this decision is non-trivial per trigger conditions; if so, proceed — otherwise skip without guilt. |
-| "Reviewer disagrees means I'm wrong" | Reviewer lacks your context; disagreement is information, not a verdict. RECONCILE then decide. | Classify the finding via RECONCILE: contract fix, valid trade-off, or noise — then proceed on that basis. |
-
-## Red Flags
-
-- Skipping doubt steps because "I'm confident"
-- Treating reviewer output as authoritative rather than informational
-- Looping past 3 cycles without escalating to the user
-- Reviewer prompt uses "is this good?" instead of "find problems"
-- 2+ consecutive cycles with substantive findings but 0 classified as "actionable" — you are validating, not doubting
-- Passing CLAIM to the reviewer (biases toward agreement)
-- Doubt theater: spawning a reviewer against an unchanged artifact (getting the same finding = stalling)
-
-## Relationship to Existing Systems
-
-- before-dev: doubt-review is a sub-step of the before-dev gate for L2 tasks
-- check: check verifies implementation correctness; doubt-review questions decision direction. Use both.
-- party-mode: board discussion can produce CLAIMs, but cannot substitute for fresh-context doubt review
-- TDD: the RED step of TDD is doubt made concrete — a failing test is a disproof attempt
-- break-loop: when a reviewer finds a true failure mode, connect to the debugging skill to locate and fix
-
-## Verification
-
-- Every non-trivial decision has a CLAIM record
-- Every non-trivial artifact undergoes at least one fresh-context review
-- Reviewer receives ARTIFACT + CONTRACT (not CLAIM)
-- Findings are classified (not rubber-stamped)
-- Stop conditions are satisfied

package/template/skills/finish-work/SKILL.md

@@ -1,32 +0,0 @@
----
-name: finish-work
-description: Use when implementation and verification are complete and cowork-flow work needs final scope review, commit/archive/session recording, or handoff.
----
-
-# Finish Work
-
-Use this in the main session after implementation and `check` are complete.
-
-## Gate
-
-Before claiming completion, verify:
-
-- Active task exists, or the work was explicitly read-only/no-task.
-- `check` or equivalent final review ran.
-- `git diff` was reviewed for scope.
-- Relevant tests, build, lint, or focused validation ran.
-- `.cowork-flow/spec/` was updated when the change created durable knowledge.
-- Plan checkboxes and task status match reality.
-- No unrelated dirty files are staged.
-
-## Sequence
-
-1. Run `git status --short`.
-2. Run `git diff --check`.
-3. Run focused tests and then broader project verification when appropriate.
-4. Update the plan/task status.
-5. Archive completed task/change artifacts when requested or required by workflow.
-6. Record the session with `.cowork-flow/run add-session --commit "-"` unless a prior commit hash is intentionally being recorded.
-7. If commit policy allows, stage only expected files and commit once.
-
-If the user asks not to commit, stop before staging and report the verified state.