@duypham93/openkit 0.2.0

package/docs/operations/runbooks/openkit-daily-usage.md

@@ -0,0 +1,288 @@
+# OpenKit Daily Usage
+
+Use this runbook when you want the practical step-by-step path for working with the globally installed OpenKit kit and its workspace-specific runtime state.
+
+## Current Reality In This Repository
+
+- The preferred operator path is now the global OpenKit install under the OpenCode home directory.
+- OpenKit workspace state is created per project in global storage instead of requiring the kit to be copied into each repository.
+- The checked-in `.opencode/` runtime in this repository remains the authoring and compatibility surface.
+- The workflow supports three live modes: `quick`, `migration`, and `full`.
+- `Quick Task+` is the current semantics of the `quick` lane, not a third mode.
+- There is no repo-native application build, lint, or test command yet, so verification must use the real runtime checks plus honest manual or artifact-based validation.
+
+## Fast Path
+
+For normal day-to-day use on a machine with OpenKit installed globally:
+
+```bash
+npm install -g openkit
+openkit run
+openkit doctor
+```
+
+Lifecycle commands:
+
+```bash
+openkit upgrade
+openkit uninstall
+```
+
+Then start work from the chat surface with one of these:
+
+- `/task` when you want the Master Orchestrator to choose the lane
+- `/quick-task` when the work is already clearly small, bounded, and low risk
+- `/migrate` when the work is primarily an upgrade or migration effort
+- `/delivery` when the work clearly needs the full multi-stage delivery flow
+
+If you need to inspect the current state more closely inside this repository's compatibility runtime:
+
+```bash
+node .opencode/workflow-state.js show
+node .opencode/workflow-state.js validate
+```
+
+## Choose The Right Entry Point
+
+Use `/task` by default. It is the safest starting point when you are not fully sure whether the request belongs in `Quick Task`, `Migration`, or `Full Delivery`.
+
+Use `/quick-task` only when all of these are already true:
+
+- the scope is bounded
+- acceptance is already clear
+- no architecture or contract change is needed
+- no security, auth, billing, permission, schema, or API model change is involved
+- verification stays short and direct
+
+Use `/delivery` when any of these are true:
+
+- the work is a new feature or workflow
+- requirements may still move
+- multiple subsystems are involved
+- architecture or contracts may change
+- you need briefs, specs, architecture, plans, or QA artifacts
+
+Use `/migrate` when most of these are true:
+
+- the main goal is upgrading or replacing existing technology
+- the expected outcome is preserving layout, behavior, and contracts under a newer stack
+- current-state baseline capture is required before editing
+- compatibility risk is more central than feature definition
+- framework-coupled blockers need seams or adapters before the upgrade is safe
+- rollback checkpoints or staged remediation are needed
+- validation depends on builds, tests, smoke checks, type checks, or manual regression evidence more than on greenfield TDD slices
+
+Canonical lane rules live in `context/core/workflow.md`.
+
+If the boundary still feels fuzzy, use the `Lane Decision Matrix` in `context/core/workflow.md` before forcing a lane.
+
+## Daily Operator Flow
+
+### 1. Check global install and workspace health
+
+Start with read-only checks:
+
+```bash
+openkit doctor
+```
+
+What to look for:
+
+- `doctor` confirms the global kit is installed, the workspace root is available, and the current project can launch with OpenKit cleanly
+
+If `doctor` reports `install-missing`, run `openkit run` for first-time setup. If `doctor` reports other errors, fix those before trusting resume or task-board behavior.
+
+### 2. Launch OpenKit for the current project
+
+```bash
+openkit run
+```
+
+This launches OpenCode with the `openkit` profile and injects the workspace-specific OpenKit environment for the current project.
+
+On the first run on a machine or a fresh OpenCode home, `openkit run` also materializes the managed global kit automatically.
+
+### 3. Start or resume work
+
+If no work is active, start from chat with `/task`, `/quick-task`, or `/delivery`.
+
+If work already exists, inspect it first:
+
+```bash
+node .opencode/workflow-state.js show
+node .opencode/workflow-state.js list-work-items
+node .opencode/workflow-state.js show-work-item <work_item_id>
+```
+
+Use `show` when you want the raw active state, linked artifacts, approvals, and open issues.
+
+Use `list-work-items` and `show-work-item` when you need to understand which managed item is active or switch your attention to a different full-delivery item.
+
+### 4. Follow the lane that was chosen
+
+Quick lane flow:
+
+- `quick_intake -> quick_plan -> quick_build -> quick_verify -> quick_done`
+- use it for bounded daily work
+- `quick_plan` is required, even though a separate task card in `docs/tasks/` remains optional
+- QA still happens through the quick verification step; quick does not bypass quality
+
+Full-delivery flow:
+
+- `full_intake -> full_brief -> full_spec -> full_architecture -> full_plan -> full_implementation -> full_qa -> full_done`
+- use it for feature work and higher-risk changes
+- expect explicit artifacts under `docs/briefs/`, `docs/specs/`, `docs/architecture/`, `docs/plans/`, and `docs/qa/`
+- use `/brainstorm`, `/write-plan`, and `/execute-plan` only in this lane
+
+Migration flow:
+
+- `migration_intake -> migration_baseline -> migration_strategy -> migration_upgrade -> migration_verify -> migration_done`
+- use it for framework upgrades, dependency modernization, and compatibility remediation
+- expect explicit baseline, architecture, and plan context before major edits
+- preserve behavior first, decouple only the blockers that make the migration unsafe, then upgrade in slices
+- use `/brainstorm`, `/write-plan`, and `/execute-plan` in this lane when strategy or staged execution is needed
+- use `docs/templates/migration-baseline-checklist.md` and `docs/templates/migration-verify-checklist.md` as repeatable checklists for baseline and verification
+- use `docs/templates/migration-report-template.md` when you want one running artifact for baseline, strategy, execution, and verification
+
+### 4. Inspect work-item and task-board state when needed
+
+The task board belongs only to `Full Delivery` work items.
+
+Useful commands:
+
+```bash
+node .opencode/workflow-state.js list-work-items
+node .opencode/workflow-state.js show-work-item <work_item_id>
+node .opencode/workflow-state.js list-tasks <work_item_id>
+node .opencode/workflow-state.js validate-work-item-board <work_item_id>
+```
+
+Guidance:
+
+- use `list-tasks` only for full-delivery items that actually use a task board
+- do not expect quick or migration mode to have task-level ownership or task-board commands
+- treat task-board support as bounded coordination, not as proof that arbitrary parallel execution is safe
+
+### 5. Validate honestly
+
+In this repository, the workflow-state utility helps you validate runtime state, not application behavior.
+
+Use:
+
+```bash
+node .opencode/workflow-state.js validate
+```
+
+for workflow-state consistency.
+
+Do not present `status`, `doctor`, `show`, or `validate` as substitutes for application build, lint, or test commands. If app-native tooling does not exist for the work, record the real manual or artifact-based verification path instead.
+
+## Command Reference For Operators
+
+Read-only commands you will use most often:
+
+| Command | Use it when | Notes |
+| --- | --- | --- |
+| `node .opencode/workflow-state.js status` | you want the current runtime summary | safest first check |
+| `node .opencode/workflow-state.js doctor` | you want diagnostics for the checked-in runtime | confirms runtime health and contract alignment |
+| `node .opencode/workflow-state.js show` | you need the active state object and linked artifacts | good for resume and debugging |
+| `node .opencode/workflow-state.js validate` | you suspect the state may be stale or manually edited | workflow-state check only |
+| `node .opencode/workflow-state.js list-work-items` | you want to see tracked work items | marks the active item |
+| `node .opencode/workflow-state.js show-work-item <work_item_id>` | you want one item's mode, stage, and status | full-delivery coordination helper |
+| `node .opencode/workflow-state.js list-tasks <work_item_id>` | you need task-board visibility for a full item | quick and migration modes stay task-board free |
+
+Lower-level mutation commands exist, but they are operator and maintainer tools. Use them intentionally and prefer the documented lane commands and approved workflow over direct manual state manipulation.
+
+The authoritative full command inventory lives in `context/core/project-config.md`.
+
+## Practical Examples
+
+### Example: start a small bounded fix
+
+1. Run:
+
+```bash
+node .opencode/workflow-state.js status
+node .opencode/workflow-state.js doctor
+```
+
+2. In chat, use:
+
+```text
+/quick-task Fix the wording in docs/operator/README.md so it matches the current lane terminology.
+```
+
+3. Let the quick lane move through `quick_plan`, implementation, and QA Lite.
+
+### Example: start feature work
+
+1. Run:
+
+```bash
+node .opencode/workflow-state.js status
+node .opencode/workflow-state.js doctor
+```
+
+2. In chat, use:
+
+```text
+/delivery Add a clearer operator onboarding flow for OpenKit, including updated docs and runtime guidance.
+```
+
+3. Expect the work to move through PM, BA, Architect, Tech Lead, Fullstack, and QA stages, with artifacts created as the full lane progresses.
+
+### Example: start migration work
+
+1. Run:
+
+```bash
+node .opencode/workflow-state.js status
+node .opencode/workflow-state.js doctor
+```
+
+2. In chat, use:
+
+```text
+/migrate Upgrade a legacy React 16 app to React 19 and modernize the async data layer safely.
+```
+
+3. Expect the work to move through baseline capture, migration strategy, staged upgrade execution, and regression-focused verification.
+
+### Example: resume an existing full-delivery item
+
+Run:
+
+```bash
+node .opencode/workflow-state.js status
+node .opencode/workflow-state.js show
+node .opencode/workflow-state.js list-work-items
+node .opencode/workflow-state.js show-work-item feature-001
+node .opencode/workflow-state.js list-tasks feature-001
+```
+
+Use the output to confirm the active stage, linked artifacts, and any task-board state before continuing.
+
+## Global Kit Note
+
+The preferred top-level path is now:
+
+```bash
+npm install -g openkit
+openkit run <args>
+openkit doctor
+openkit upgrade
+openkit uninstall
+```
+
+`openkit install-global` still exists as a manual or compatibility setup command, but it is no longer the preferred onboarding step.
+
+Use the lower-level `.opencode/` runtime commands in this repository when you are validating or maintaining the checked-in compatibility runtime itself.
+
+## Where To Read Next
+
+- `README.md` for the top-level runtime and product-boundary summary
+- `docs/operator/README.md` for operator routing
+- `context/core/workflow.md` for canonical lane rules and stage order
+- `context/core/project-config.md` for the maintained command inventory
+- `context/core/session-resume.md` for resume behavior
+- `docs/operations/runbooks/workflow-state-smoke-tests.md` for deeper verification and manual smoke-test procedures

package/docs/operations/runbooks/workflow-state-smoke-tests.md

@@ -0,0 +1,302 @@
+# Workflow-State Smoke Tests
+
+Use this document to run lightweight verification for the global OpenKit install path and for the lower-level workflow-state utility and session-start resume hint that still sit underneath it.
+
+## Safety First
+
+Many commands in this document mutate project state. Do not run the manual examples against the checked-in repository state unless you intentionally want to change it.
+
+Use one of these safer approaches before running any mutating command shown later in this document:
+
+- work in a temporary throwaway repository when validating first-run `openkit run`, manual `openkit install-global`, or workspace bootstrap handling
+- use a temporary state file or temporary project copy when validating `node .opencode/workflow-state.js` mutation commands
+- if you must point at this repository, restore any changed files immediately after the check
+
+High-risk mutating commands called out in this document include:
+
+- `openkit run`
+- `openkit install-global`
+- `node .opencode/workflow-state.js sync-install-manifest <name>`
+- `node .opencode/workflow-state.js start-task ...`
+- `node .opencode/workflow-state.js advance-stage ...`
+- `node .opencode/workflow-state.js route-rework ...`
+- `node .opencode/workflow-state.js create-task ...`
+
+Read this safety section before copying any command block below.
+
+## Purpose
+
+These checks validate OpenKit's supported wrapper operator path plus the workflow operating system behavior underneath it, without assuming any application build, lint, or test stack.
+
+## Supported Path Order
+
+When you are validating operator-facing behavior, treat this order as primary:
+
+1. `npm install -g openkit`
+2. `openkit run`
+3. `openkit doctor`
+4. `node .opencode/workflow-state.js ...` only when you need raw repository/runtime inspection
+
+## Automated Checks
+
+### Controller unit tests
+
+Run:
+
+```bash
+node --test ".opencode/tests/workflow-state-controller.test.js"
+```
+
+This covers:
+
+- quick-task initialization
+- full-delivery initialization
+- mode-aware approvals
+- valid and invalid stage transitions
+- quick-to-full escalation routing
+- compatibility behavior for `start-feature`
+
+### Session-start hook test
+
+Run:
+
+```bash
+node --test ".opencode/tests/session-start-hook.test.js"
+```
+
+This verifies that the session-start hook emits a mode-aware `workflow_resume_hint` when state exists, plus the canonical startup command hints used for status inspection.
+
+If the JSON helper used by `session-start` is unavailable, expect a degraded runtime-status block instead of a hard failure. In that case, resume hints may be suppressed until the helper works again.
+
+### Contract-consistency tests
+
+Run:
+
+```bash
+node --test ".opencode/tests/workflow-contract-consistency.test.js"
+```
+
+This covers:
+
+- declared command and agent surfaces exist where the manifest says they do
+- workflow contract and workflow-state schema files are present
+- schema/runtime parity checks for mode enums, stage names, artifact slots, and approval keys
+- `doctor` surfacing contract-consistency failures when those invariants drift
+
+### Runtime CLI tests
+
+Run:
+
+```bash
+node --test ".opencode/tests/workflow-state-cli.test.js"
+```
+
+This covers:
+
+- `status` output for runtime summary fields
+- `doctor` output for runtime diagnostics
+- `profiles` output for checked-in profile listing
+- `show-profile` output for profile detail inspection
+- `sync-install-manifest` behavior for local manifest updates
+- non-zero `doctor` exit behavior when required runtime files are missing
+- quick-lane stage behavior such as `quick_plan` when live contract changes land in runtime tests
+- work-item and task-board summaries in `status` and `doctor` output when full-delivery parallel state is active
+
+### Wrapper CLI smoke tests
+
+Run:
+
+```bash
+node --test tests/cli/openkit-cli.test.js
+```
+
+This covers:
+
+- first-run `openkit run` on a fresh machine or temp OpenCode home
+- `openkit doctor` after global install in a repository with an existing `.opencode/opencode.json`
+- `openkit run` launching a mocked `opencode` through the managed layering path
+- workspace bootstrap and global profile wiring
+
+## Manual CLI Smoke Tests
+
+Run the manual checks below only in a throwaway repo or temporary project copy unless the step explicitly says it is read-only.
+
+### Global install and launch path
+
+On a fresh machine or temporary OpenCode home:
+
+```bash
+npm install -g openkit
+openkit run
+openkit doctor
+```
+
+Expected outcome:
+
+- the first `openkit run` materializes the kit under the OpenCode home directory automatically
+- `openkit doctor` reports global kit and workspace readiness
+- `openkit install-global` remains available when you want to force the manual setup path explicitly
+
+In a repository that already has `.opencode/opencode.json`:
+
+```bash
+openkit doctor
+openkit run --help
+```
+
+Expected outcome:
+
+- `openkit doctor` reports workspace readiness without requiring the kit to be copied into the repository
+- `openkit run` remains the supported launcher path over the raw runtime internals
+
+### Workspace bootstrap reporting
+
+Expected outcome after `openkit doctor` in a new repository:
+
+- the command reports the workspace root under the OpenCode home directory
+- the command reports the resolved project root
+- the command reports the workspace id used for this repository
+
+### Runtime summary and diagnostics
+
+```bash
+node .opencode/workflow-state.js status
+node .opencode/workflow-state.js doctor
+```
+
+Expected outcome:
+
+- `status` prints the active runtime summary using the current state file, including the active profile plus registry and install-manifest paths
+- `doctor` reports repository runtime checks instead of application-tooling health
+- `doctor` includes contract-consistency checks for declared runtime surfaces and schema alignment
+- `doctor` also checks active work-item pointer resolution, compatibility-mirror alignment, and task-board validity when the active full-delivery stage depends on task-board state
+- `doctor` exits successfully only when required OpenKit runtime files are present
+
+### Managed work-item inspection
+
+```bash
+node .opencode/workflow-state.js list-work-items
+node .opencode/workflow-state.js show-work-item feature-001
+```
+
+Expected outcome:
+
+- `list-work-items` prints `Active work item:` and marks the active item with `*`
+- `show-work-item feature-001` prints `Work item: feature-001`
+- `show-work-item feature-001` prints the work item's mode, stage, and status
+
+### Profile inspection
+
+```bash
+node .opencode/workflow-state.js profiles
+node .opencode/workflow-state.js show-profile openkit-core
+```
+
+Expected outcome:
+
+- `profiles` starts with `OpenKit profiles:`
+- the repository default profile is marked with `*`
+- `show-profile openkit-core` prints `Profile: openkit-core`
+- `show-profile openkit-core` prints `default: yes`
+- `show-profile openkit-core` prints a comma-separated `components:` line using registry category names such as `agents`, `skills`, `commands`, `artifacts`, `runtime`, `hooks`, and `docs`
+
+### Install-manifest sync
+
+Work on a throwaway branch, temporary project copy, or restore the checked-in manifest immediately after this check. `sync-install-manifest` rewrites the install manifest for the project root implied by the current `--state` path. If `--state` still points at this repository, the checked-in `.opencode/install-manifest.json` is what will change.
+
+```bash
+node .opencode/workflow-state.js sync-install-manifest runtime-docs-surface
+node .opencode/workflow-state.js status
+```
+
+Expected outcome:
+
+- `sync-install-manifest runtime-docs-surface` prints `Updated install manifest profile to 'runtime-docs-surface'`
+- the next `status` output shows `active profile: runtime-docs-surface`
+- `.opencode/install-manifest.json` records `installation.activeProfile = runtime-docs-surface`
+- no agent, skill, command, or doc files are created or removed by this command; only local metadata changes
+
+To restore the repository-default manifest after the check:
+
+```bash
+node .opencode/workflow-state.js sync-install-manifest openkit-core
+```
+
+Expected outcome:
+
+- the command prints `Updated install manifest profile to 'openkit-core'`
+- `.opencode/install-manifest.json` returns to `installation.activeProfile = openkit-core`
+
+### Quick Task happy path
+
+```bash
+node .opencode/workflow-state.js start-task quick TASK-900 copy-fix "Scoped text change"
+node .opencode/workflow-state.js advance-stage quick_plan
+node .opencode/workflow-state.js advance-stage quick_build
+node .opencode/workflow-state.js advance-stage quick_verify
+node .opencode/workflow-state.js set-approval quick_verified approved system 2026-03-21 "QA Lite passed"
+node .opencode/workflow-state.js advance-stage quick_done
+node .opencode/workflow-state.js show
+```
+
+Expected outcome:
+
+- `mode = quick`
+- `current_stage = quick_done`
+- `status = done`
+
+### Quick Task escalation path
+
+```bash
+node .opencode/workflow-state.js start-task quick TASK-901 needs-spec "Initially looked small"
+node .opencode/workflow-state.js route-rework design_flaw
+node .opencode/workflow-state.js show
+```
+
+Expected outcome:
+
+- `mode = full`
+- `current_stage = full_intake`
+- `escalated_from = quick`
+- non-null `escalation_reason`
+
+### Full Delivery bug rework path
+
+```bash
+node .opencode/workflow-state.js start-task full FEATURE-900 dashboard-v2 "Feature workflow"
+node .opencode/workflow-state.js route-rework bug true
+node .opencode/workflow-state.js show
+```
+
+Expected outcome:
+
+- `mode = full`
+- `current_stage = full_implementation`
+- `retry_count = 1`
+
+### Full-delivery task-board inspection
+
+```bash
+node .opencode/workflow-state.js start-task full FEATURE-910 board-check "Board setup"
+node .opencode/workflow-state.js create-task feature-910 TASK-910-A "Implement diagnostics" implementation
+node .opencode/workflow-state.js list-tasks feature-910
+node .opencode/workflow-state.js validate-work-item-board feature-910
+```
+
+Expected outcome:
+
+- `create-task` initializes the task board for the new full-delivery work item
+- `list-tasks feature-910` prints `Tasks for feature-910:` followed by task rows
+- `validate-work-item-board feature-910` prints `Task board is valid for work item 'feature-910'`
+
+## Notes
+
+- Keep wrapper smoke coverage and the wrapper walkthrough example aligned with the actual `openkit` CLI behavior.
+- Keep `openkit doctor` guidance separate from `node .opencode/workflow-state.js doctor`; they validate different layers.
+- Prefer using a temporary state file when running manual smoke tests so the checked-in `.opencode/workflow-state.json` remains stable.
+- For task-aware smoke tests, prefer a temporary project copy rooted around `.opencode/workflow-state.json` so the compatibility mirror, work-item store, and install manifest can be exercised together.
+- Be deliberate when running `sync-install-manifest` because it updates the install manifest associated with the resolved project root, not the `--state` file itself. If that root is this repository, the checked-in `.opencode/install-manifest.json` will change.
+- If workflow rules change, update this file alongside the tests and the workflow-state CLI docs.
+- If session-start output changes, update this file, `README.md`, and any example docs that describe bootstrap behavior in the same change.
+- If registry categories, profile names, or manifest semantics change, update this file together with `README.md`, `docs/operations/README.md`, and the relevant governance notes.
+- Prefer behavior-oriented checks over purely structural checks whenever a workflow contract can be observed from CLI output, resume hints, or lane transitions.

package/docs/operator/README.md

@@ -0,0 +1,50 @@
+# Operator Guide
+
+This directory is the operator-facing index layer for phase 1 information architecture.
+
+Use it to find the right live docs quickly. Do not treat it as a canonical replacement for the docs it points to.
+
+## Phase-1 Authority Rule
+
+- this directory is an index, not a moved source-of-truth surface
+- `README.md` remains the concise top-level repository entrypoint
+- `context/core/workflow.md` remains the canonical live workflow-semantics document
+- companion operational details remain canonical in `context/core/`
+- governance and operations policies remain canonical in `docs/governance/` and `docs/operations/`
+
+## Start Here
+
+- Read `README.md` for the top-level product and runtime boundary summary
+- Read `docs/operations/runbooks/openkit-daily-usage.md` for the detailed day-to-day usage path in this repository
+- Install the CLI with `npm install -g openkit`, then run `openkit run` for first-time setup and `openkit doctor` to verify readiness
+- Use `/task` unless you already know the work must start in `Quick Task`, `Migration`, or `Full Delivery`
+- Use `context/navigation.md` when you need to locate deeper workflow or standards references
+
+## Operator Routes
+
+- Workflow contract: `context/core/workflow.md`
+- Lane examples and tie-breakers: `context/core/workflow.md`
+- Session resume: `context/core/session-resume.md`
+- Command and runtime reality: `context/core/project-config.md`
+- Detailed usage walkthrough: `docs/operations/runbooks/openkit-daily-usage.md`
+- Runtime smoke tests: `docs/operations/runbooks/workflow-state-smoke-tests.md`
+- Governance policy: `docs/governance/README.md`
+- Operations support: `docs/operations/README.md`
+
+## Live Operator Surfaces In This Repository
+
+- Slash commands: `/task`, `/quick-task`, `/migrate`, `/delivery`, `/brainstorm`, `/write-plan`, `/execute-plan`
+- Global diagnostics: `openkit doctor`
+- Global launcher: `openkit run`
+- Global lifecycle: `npm install -g openkit`, `openkit upgrade`, `openkit uninstall`
+- Runtime inspection: `node .opencode/workflow-state.js status`
+- Compatibility diagnostics: `node .opencode/workflow-state.js doctor`
+- Current state view: `node .opencode/workflow-state.js show`
+- Validation: `node .opencode/workflow-state.js validate`
+
+## Boundary Notes
+
+- The preferred user path is the global OpenKit install in the OpenCode home directory
+- `openkit install-global` remains available as a manual or compatibility setup command, but it is no longer the preferred onboarding step
+- `.opencode/opencode.json` remains the checked-in authoring and compatibility runtime manifest in this repository
+- `Quick Task+` remains the current semantics of the `quick` lane, not a third live mode

package/docs/plans/2026-03-20-task-intake-dashboard.md

@@ -0,0 +1,49 @@
+---
+artifact_type: implementation_plan
+version: 1
+status: approved
+feature_id: FEATURE-001
+feature_slug: task-intake-dashboard
+source_architecture: docs/architecture/2026-03-20-task-intake-dashboard.md
+owner: TechLeadAgent
+approval_gate: tech_lead_to_fullstack
+---
+
+# Implementation Plan: Task Intake Dashboard
+
+## Goal
+
+Implement the smallest possible intake dashboard flow that satisfies the approved spec.
+
+## Dependencies
+
+- No repo-native application stack or test runner is defined yet.
+- Validation path: artifact review and workflow consistency only.
+
+## Tasks
+
+### [x] Task 1: Define list behavior
+- Files: `docs/specs/2026-03-20-task-intake-dashboard.md`
+- Goal: capture list and empty-state behavior clearly
+- Validation: spec review against acceptance criteria
+- Notes: no repo-native test command exists yet
+
+### [x] Task 2: Define architecture boundaries
+- Files: `docs/architecture/2026-03-20-task-intake-dashboard.md`
+- Goal: isolate query, normalization, and rendering responsibilities
+- Validation: architecture review against spec
+- Notes: no repo-native test command exists yet
+
+### [x] Task 3: Prepare implementation guidance
+- Files: `docs/plans/2026-03-20-task-intake-dashboard.md`
+- Goal: hand off a minimal executable plan for future application code
+- Validation: plan review against templates and workflow contracts
+- Notes: validation path is documentation-based until a toolchain exists
+
+## Risks
+
+- Future application stack may require rewriting validation commands.
+
+## Rollback Notes
+
+- Revert to the previous artifact set if this golden path no longer reflects the workflow model.