cc-devflow 4.2.0 → 4.4.1

package/docs/examples/START-HERE.md

@@ -0,0 +1,149 @@
+# Start Here
+
+This is the **single entry page** for the example set.
+
+Use it in any of these situations:
+
+- you want the fastest path to the right example
+- you only know your current symptom
+- you only know which artifact file you have
+- you want one-page context before diving into the examples
+
+## Version Trust
+
+Examples are pinned to current skill versions through:
+
+- [example-bindings.json](./example-bindings.json): canonical bindings for example-to-skill versions
+- [scripts/check-example-bindings.sh](./scripts/check-example-bindings.sh): verifies the bindings against current `SKILL.md` versions and example artifacts
+
+For day-to-day work, the shortest habit is:
+
+```bash
+npm run verify
+```
+
+For publish-grade validation, use:
+
+```bash
+npm run verify:publish
+```
+
+## Fast Route
+
+### 1. Do you already have a `report-card.json` verdict?
+
+- If **no**, start with [the happy path example](./pdca-loop/README.md) to understand the full loop once.
+- If **yes**, continue below.
+
+### 2. Is the verdict `pass`?
+
+- If **no**, go to [the full-design blocked example](./full-design-blocked/README.md).
+  It shows the most important non-happy-path truth:
+  green tests do not override a broken planning contract.
+- If **yes**, continue below.
+
+### 3. Can you honestly create or update a PR right now?
+
+- If **yes**, go to [the happy path example](./pdca-loop/README.md).
+  That sample ends in `create-pr`.
+- If **no**, go to [the local-handoff example](./local-handoff/README.md).
+  That sample shows how verified work still leaves a clean next entry without pretending to ship.
+
+## Symptom Picker
+
+| If your situation feels like this | Read this example first | Why |
+| --- | --- | --- |
+| "I just want to understand the normal loop once." | [pdca-loop](./pdca-loop/README.md) | shows the straight-through path |
+| "The code is locally green, but I don't trust the requirement anymore." | [full-design-blocked](./full-design-blocked/README.md) | shows `blocked` + reroute to `cc-plan` |
+| "The work is verified, but I can't or shouldn't push yet." | [local-handoff](./local-handoff/README.md) | shows `pass` + `local-handoff` |
+| "I don't know whether this should stay `tiny-design`." | [pdca-loop](./pdca-loop/README.md), then [full-design-blocked](./full-design-blocked/README.md) | compare a truly small patch against a requirement that outgrew it |
+
+## By Artifact
+
+Use this when the only thing you know is the file in front of you.
+
+| If the main file you have is... | You are probably here | Read this first |
+| --- | --- | --- |
+| `ROADMAP.md` | `cc-roadmap` | [pdca-loop/ROADMAP.md](./pdca-loop/ROADMAP.md) |
+| `roadmap-tracking.json` | `cc-roadmap` machine truth source for roadmap + backlog | [pdca-loop/roadmap-tracking.json](./pdca-loop/roadmap-tracking.json) |
+| `BACKLOG.md` | `cc-roadmap` -> `cc-plan` handoff | [pdca-loop/BACKLOG.md](./pdca-loop/BACKLOG.md) |
+| `design.md` | `cc-plan` | [pdca-loop/design.md](./pdca-loop/changes/REQ-001-copy-invite-link/planning/design.md) or [full-design-blocked/design.md](./full-design-blocked/changes/REQ-002-bulk-invite-import/planning/design.md) |
+| `tasks.md` | `cc-plan` or `cc-do` | [pdca-loop/tasks.md](./pdca-loop/changes/REQ-001-copy-invite-link/planning/tasks.md) |
+| `task-manifest.json` | `cc-do` | [pdca-loop/task-manifest.json](./pdca-loop/changes/REQ-001-copy-invite-link/planning/task-manifest.json) |
+| `report-card.json` | `cc-check` | [pdca-loop/report-card.json](./pdca-loop/changes/REQ-001-copy-invite-link/review/report-card.json), [full-design-blocked/report-card.json](./full-design-blocked/changes/REQ-002-bulk-invite-import/review/report-card.json), or [local-handoff/report-card.json](./local-handoff/changes/REQ-003-audit-log-export/review/report-card.json) |
+| `pr-brief.md` | `cc-act` | [pdca-loop/pr-brief.md](./pdca-loop/changes/REQ-001-copy-invite-link/handoff/pr-brief.md) |
+| `resume-index.md` | `cc-act` with `local-handoff` | [local-handoff/resume-index.md](./local-handoff/changes/REQ-003-audit-log-export/handoff/resume-index.md) |
+
+### Read `report-card.json` Like This
+
+| Verdict | Reroute | Meaning |
+| --- | --- | --- |
+| `pass` | `none` | move toward `cc-act` |
+| `fail` | `cc-do` | implementation must continue |
+| `blocked` | `cc-do` | proof or execution prerequisites are missing |
+| `blocked` | `cc-plan` | design or scope truth is broken; do not keep coding blindly |
+
+### Read `resume-index.md` Like This
+
+Ask only:
+
+1. is verification already `pass`?
+2. is the blocker environmental instead of design-related?
+
+If both are true, you are usually in `cc-act` local handoff territory, not back in planning.
+
+## Example Map
+
+### 1. Happy Path: `tiny-design` + `pass` + `create-pr`
+
+- Read: [pdca-loop/README.md](./pdca-loop/README.md)
+- Best when:
+  - you want to understand the straight-through loop once
+  - you need a clean example of `cc-roadmap -> cc-plan -> cc-do -> cc-check -> cc-act`
+
+### 2. Counterexample: `full-design` + `blocked` + reroute to `cc-plan`
+
+- Read: [full-design-blocked/README.md](./full-design-blocked/README.md)
+- Best when:
+  - tests are green but the requirement still feels untrustworthy
+  - you need to see why `cc-check` can honestly block even after execution work happened
+
+### 3. Counterexample: `pass` + `local-handoff`
+
+- Read: [local-handoff/README.md](./local-handoff/README.md)
+- Best when:
+  - the work is verified
+  - but PR or remote actions are intentionally unavailable
+  - and you need a clean next-entry handoff instead of fake shipping
+
+## Wrong Turns To Avoid
+
+- Do not jump from `tasks.md` straight to `cc-act`
+- Do not treat green tests as stronger than a `report-card.json` reroute
+- Do not treat `resume-index.md` as proof that planning failed; it may simply mean local handoff
+
+## One-Minute Rule
+
+If you only have one minute, open these files in order:
+
+1. example `README.md`
+2. change `planning/design.md`
+3. `report-card.json` or the single final handoff file
+
+That should already tell you:
+
+- what planning density was chosen
+- whether verification passed, failed, or blocked
+- why `cc-act` selected the final ship mode
+
+## Minimal Output Rule
+
+`devflow/changes/<change>/` should stay lean.
+
+- Durable truth only: `change-state.json`, planning docs, `task-manifest.json`, optional `team-state.json`, task `checkpoint.json`, `report-card.json`, and one final handoff file.
+- Runtime scratch belongs in `devflow/workspaces/<change>/`, not beside the durable record.
+
+## If You Still Want The Split Views
+
+- [README.md](./README.md): compact example list
+- [BY-ARTIFACT.md](./BY-ARTIFACT.md): compatibility page for artifact-only lookup

package/docs/examples/example-bindings.json

@@ -0,0 +1,38 @@
+{
+  "updatedAt": "2026-04-25",
+  "skills": {
+    "cc-roadmap": "4.3.1",
+    "cc-plan": "3.5.3",
+    "cc-investigate": "1.1.1",
+    "cc-do": "1.5.1",
+    "cc-check": "1.8.1",
+    "cc-act": "1.6.1",
+    "cc-spec-init": "1.0.0"
+  },
+  "examples": [
+    {
+      "id": "pdca-loop",
+      "readme": "docs/examples/pdca-loop/README.md",
+      "root": "docs/examples/pdca-loop",
+      "changeDir": "docs/examples/pdca-loop/changes/REQ-001-copy-invite-link",
+      "covers": ["cc-roadmap", "cc-plan", "cc-do", "cc-check", "cc-act"],
+      "expectedShipMode": "create-pr"
+    },
+    {
+      "id": "full-design-blocked",
+      "readme": "docs/examples/full-design-blocked/README.md",
+      "root": "docs/examples/full-design-blocked",
+      "changeDir": "docs/examples/full-design-blocked/changes/REQ-002-bulk-invite-import",
+      "covers": ["cc-roadmap", "cc-plan", "cc-do", "cc-check"],
+      "expectedShipMode": "none"
+    },
+    {
+      "id": "local-handoff",
+      "readme": "docs/examples/local-handoff/README.md",
+      "root": "docs/examples/local-handoff",
+      "changeDir": "docs/examples/local-handoff/changes/REQ-003-audit-log-export",
+      "covers": ["cc-roadmap", "cc-plan", "cc-do", "cc-check", "cc-act"],
+      "expectedShipMode": "local-handoff"
+    }
+  ]
+}

package/docs/examples/full-design-blocked/BACKLOG.md

@@ -0,0 +1,45 @@
+# BACKLOG
+
+## Backlog Meta
+
+- Roadmap version: `roadmap.v2`
+- Skill version: `4.3.1`
+- Last synced: `2026-04-19`
+- Current focus stage: `Stage 2`
+- Tracking source: `roadmap-tracking.json`
+
+## Queue
+
+| RM-ID | Title | Source Stage | Priority | Primary Capability | Secondary Capabilities | Capability Gap | Expected Spec Delta | Evidence | Depends On | Parallel With | Unknowns | Next Decision | Ready |
+|------|------|------|------|------|------|------|------|------|------|------|------|------|------|
+| RM-010 | Add CSV bulk invite import for admins | Stage 2 | P1 | cap-bulk-invite-import | cap-workspace-membership | admins can invite one user at a time but cannot safely import invite batches | define import semantics before widening current truth | sales onboarding asks for spreadsheet-scale invites | - | - | duplicate-email policy, seat enforcement, audit fan-out | reroute to full design before more execution work | Yes |
+
+## Dependency Handoff
+
+- Serial spine: RM-010
+- Parallel-ready next wave: -
+- Notes on blockers: verification is blocked until the import contract covers limits, duplicates, billing, and audit consistency
+
+## Ready For Req-Plan
+
+- RM-010:
+  - Primary Capability: `cap-bulk-invite-import`
+  - Secondary Capabilities: `cap-workspace-membership`
+  - Why now: demand is real, but the contract is too wide to keep improvising in code
+  - Success signal: the capability has a trusted import contract before implementation resumes
+  - Entry constraints: must freeze limits, duplicates, warnings, and audit behavior first
+  - Capability gap: admins can invite one user at a time but cannot safely import invite batches
+  - Expected spec delta: define import semantics before widening current truth
+  - Open risks: another partial implementation pass would deepen the semantic drift
+  - First planning question: which subflows share one import contract and which need explicit splits?
+  - Required context to load: invite limits, billing rules, duplicate handling, audit logging
+  - Depends On: `-`
+  - Parallel With: `-`
+  - Why this is ready now: the blocker is design truth, not implementation effort
+
+## Parked
+
+- RM-XXX:
+  - Reason parked:
+  - Trigger to reopen:
+  - Missing evidence:

package/docs/examples/full-design-blocked/README.md

@@ -0,0 +1,55 @@
+# Full-Design Blocked Example
+
+## Example Meta
+
+- Example version: `1.0.0`
+- Last reviewed: `2026-04-17`
+- Bound skills: `cc-roadmap@4.3.1`, `cc-plan@3.5.3`, `cc-do@1.5.1`, `cc-check@1.8.1`
+
+This example shows a requirement that **looked executable**, but `cc-check` correctly stopped it and sent it back to `cc-plan`.
+
+The shape is intentional:
+
+- roadmap item is real enough to matter
+- design requires `full-design`
+- tasks were executed far enough to produce evidence
+- `report-card.json` is still `blocked`
+- reroute is `cc-plan`, not `cc-do`
+
+## Scenario
+
+The fictional product now wants CSV-based bulk invites for workspace admins.
+
+At first glance, it looks like an import feature inside the admin console.
+
+But the real surface is wider:
+
+- invite limit enforcement
+- duplicate email handling
+- billing-seat warnings
+- audit log consistency
+
+The sample shows what happens when implementation moved before the integration design was fully trustworthy.
+
+## What To Look For
+
+1. Why this requirement cannot stay `tiny-design`
+2. Which signals forced `full-design`
+3. Why tests passing is still not enough
+4. Why reroute goes to `cc-plan` instead of `cc-do`
+
+## Artifact Map
+
+- `ROADMAP.md`
+- `roadmap-tracking.json` (shared roadmap/backlog truth)
+- `BACKLOG.md`
+- `changes/REQ-002-bulk-invite-import/planning/design.md`
+- `changes/REQ-002-bulk-invite-import/planning/tasks.md`
+- `changes/REQ-002-bulk-invite-import/planning/task-manifest.json`
+- `changes/REQ-002-bulk-invite-import/review/report-card.json`
+
+## Why There Is No `cc-act` Output
+
+There is no final handoff file here because `cc-check` did **not** return `pass`.
+
+The loop must stop honestly before `cc-act`.

package/docs/examples/full-design-blocked/ROADMAP.md

@@ -0,0 +1,53 @@
+# ROADMAP
+
+## Roadmap Meta
+
+- Roadmap version: `roadmap.v2`
+- Skill version: `4.3.1`
+- Status: `active`
+- Last updated: `2026-04-16`
+- Owner / decider: `product-owner`
+- Current focus stage: `Stage 2`
+- Confidence: `medium`
+- Supersedes roadmap version: `roadmap.v1`
+
+## Context Snapshot
+
+- Product / repo: `workspace-lite`
+- Project stage: teams actively collaborate after the first-share fixes
+- Users: workspace admins managing larger invite waves
+- Pain: inviting many users one by one is slow and error-prone
+- Existing workaround: admins repeatedly paste emails or use external spreadsheets
+- Strongest demand evidence: support calls now ask for admin-scale invite workflows
+- Why now: the product graduated past the first-share bottleneck
+- Distribution path: direct beta expansion to larger teams
+- Deadline / forcing function: larger-team beta starts on `2026-04-30`
+- Team / capacity: one engineer plus part-time design help
+- Hard constraints: billing and audit behavior must remain trustworthy
+- Adoption / trust bottleneck: admins will not trust bulk invite if seat usage and audit logs drift
+- Known unknowns: how duplicate users, seat limits, and partial imports should behave
+
+## Route Options
+
+| Shape | Why this could work | Why this may fail | Decision |
+|-------|---------------------|-------------------|----------|
+| wedge-first | deliver a minimal CSV import | may hide dangerous admin edge cases | Rejected |
+| platform-first | design import rules, billing boundaries, and audit consistency first | slower upfront | Recommended |
+| rescue-first | keep manual import and patch docs | does not solve admin pain | Rejected |
+
+## Recommended Route
+
+- Recommendation: `platform-first`
+- Why this route wins now: the biggest risk is trust and consistency, not button placement
+- Why the rejected routes lose now: a superficially small import flow can corrupt admin expectations if rules are underspecified
+- First signal to watch: admins can predict what happens for duplicates, seat limits, and partial success
+- Kill signal / stop condition: if the team cannot specify bulk invite semantics before implementation starts
+
+## Implementation Tracking
+- Tracking source: `roadmap-tracking.json`
+
+<!-- roadmap-tracking:start -->
+| RM-ID | Item | Stage | Priority | Primary Capability | Secondary Capabilities | Expected Spec Delta | Depends On | Status | REQ | Progress |
+|------|------|------|------|------|------|------|------|------|------|------|
+| RM-010 | Add CSV bulk invite import for admins | Stage 2 | P1 | cap-bulk-invite-import | cap-workspace-membership | define import semantics before widening current truth | - | Verification blocked | REQ-002 | 80% |
+<!-- roadmap-tracking:end -->

package/docs/examples/full-design-blocked/changes/REQ-002-bulk-invite-import/planning/design.md

@@ -0,0 +1,154 @@
+# DESIGN
+
+## Document Meta
+
+- Requirement version: `REQ-002.v2`
+- Design version: `design.v2`
+- CC-Plan skill version: `3.5.3`
+- Requirement ID: `REQ-002`
+- Design mode: `full-design`
+- Why not `tiny-design`: the feature crosses import parsing, invite rules, billing limits, duplicate handling, and audit logging
+- Design status: `in-review`
+- Source roadmap item: `RM-010`
+- Source roadmap version: `roadmap.v2`
+- Source roadmap skill version: `4.1.0`
+- Date: `2026-04-16`
+- Owner: `product-owner`
+
+## Source Handoff
+
+- Source stage: `Stage 2`
+- Why now from roadmap: admin demand is real, but trust risks dominate the design
+- Inherited success signal: admins can predict every bulk invite outcome
+- Inherited kill signal: if semantics remain underspecified, stop execution and reopen planning
+- Inherited dependencies:
+  - existing seat limit enforcement
+  - current audit log contract
+- Inherited non-goals:
+  - no background job redesign
+  - no enterprise provisioning layer
+- Upstream evidence: support notes from larger teams
+- Assumptions to re-validate:
+  - duplicate emails can be skipped safely
+  - seat-limit failures can be partially accepted
+
+## Requirement Snapshot
+
+- Raw ask: admins want to upload a CSV of emails instead of inviting people one by one
+- User: workspace admins onboarding 20-200 collaborators
+- Pain: manual invites are too slow and error-prone
+- Smallest viable wedge: a CSV upload that clearly predicts accepted, skipped, and rejected rows
+- Out of scope:
+  - enterprise SCIM provisioning
+  - background retry orchestration
+
+## Success Criteria
+
+- Observable success signals:
+  - admin sees deterministic results for each CSV row
+  - duplicate, over-limit, and invalid rows are explained consistently
+- Business / operator success signals:
+  - support no longer manually explains bulk invite outcomes
+- Abort signals:
+  - billing-seat or audit outcomes differ from the documented plan
+
+## Options Considered
+
+### Option A
+
+- Shape: front-end-only CSV parsing with best-effort invite submission
+- Reuses: existing single-invite API
+- Pros: fast to prototype
+- Cons: semantics depend on hidden backend edge cases
+- Risks: partial success becomes impossible to explain
+
+### Option B
+
+- Shape: freeze a rule matrix first, then implement import around it
+- Reuses: existing invite engine, but with explicit row-state mapping
+- Pros: makes billing, duplicate, and audit behavior reviewable
+- Cons: more upfront planning
+- Risks: may expose a need for additional shared contracts
+
+## Approved Direction
+
+- Approved option: `Option B`
+- Why this is the best trade-off now: the import UX is not trustworthy until row outcomes and seat limits are explicitly modeled
+- Why not the other options now: best-effort submission would let implementation invent semantics during execution
+- What we explicitly rejected: a UI-only CSV uploader that guesses row behavior
+- Frozen decisions:
+  - bulk import must classify each row into accepted, skipped, or rejected
+  - seat-limit failures cannot silently pass
+  - audit log entries must match the visible row outcome
+- Deferred questions:
+  - whether partial success needs an explicit rollback option
+
+## Design
+
+- Modules touched:
+  - admin invite UI
+  - invite validation rules
+  - billing / seat limit decision points
+  - audit log mapping
+- Data flow:
+  - CSV parse -> row validation -> invite decision -> row result summary -> audit log write
+- Contracts:
+  - one rule matrix for duplicate, invalid, over-limit, and existing-member rows
+- Error handling:
+  - every rejected row must expose a user-readable reason
+- Rollout / migration:
+  - release only after rule matrix and verification plan are both approved
+
+## File Plan
+
+| File | Change | Reason |
+|------|--------|--------|
+| `src/admin/BulkInvitePanel.tsx` | update | upload and result display |
+| `src/admin/BulkInvitePanel.test.tsx` | update | row-state behavior tests |
+| `src/invite/bulk-import.ts` | add | import rule orchestration |
+| `src/invite/bulk-import.test.ts` | add | duplicate / seat / invalid cases |
+| `src/audit/invite-log.ts` | update | audit consistency |
+
+## Validation Strategy
+
+- Unit: rule matrix tests for each row outcome
+- Integration: admin upload flow covering duplicates and seat-limit failures
+- Manual: CSV import with mixed valid and invalid rows
+- Observability / evidence: row summary and audit log must agree
+
+## Risks
+
+| Risk | Impact | Mitigation |
+|------|--------|------------|
+| duplicate handling is underspecified | high | freeze explicit rule matrix before continuing |
+| audit and visible row summary diverge | high | verify audit mapping in integration review |
+
+## Review Gate
+
+- Placeholder scan: pass
+- Consistency scan: fail; current implementation evidence still assumes some row outcomes not frozen here
+- Scope scan: pass
+- Ambiguity scan: blocked; duplicate + seat-limit semantics still need sharper wording
+- Feasibility scan: pass
+- Source alignment: pass; roadmap still prioritizes trust over speed
+- UI / interaction review summary: result states are acceptable if semantics are frozen first
+- DX review summary: execution still needs a single row-outcome matrix
+- Auto-decided items:
+  - CSV upload stays inside admin settings
+- Taste decisions:
+  - show result rows directly after parse instead of a second confirmation wizard
+- User challenges:
+  - can admins predict partial failure without reading documentation?
+- Recommendation: do not declare this design complete until the row-outcome matrix is explicit
+
+## Approval
+
+- User approval status: `in-review`
+- Follow-up changes after review:
+  - add a rule matrix section before execution resumes
+
+## First-Read Test
+
+- 10 秒内能看出这次为什么不是 `tiny-design`
+- 10 秒内能看出批准方案和被拒方案的边界
+- `cc-do` 是否还能被迫二次设计；这里答案仍然是“会”，所以设计还不能诚实闭环

package/docs/examples/full-design-blocked/changes/REQ-002-bulk-invite-import/planning/task-manifest.json

@@ -0,0 +1,146 @@
+{
+  "changeId": "REQ-002",
+  "goal": "Add a trustworthy CSV bulk invite flow for admins without inventing row-outcome semantics during execution.",
+  "createdAt": "2026-04-16T09:00:00.000Z",
+  "updatedAt": "2026-04-16T12:00:00.000Z",
+  "requirementId": "REQ-002",
+  "requirementVersion": "REQ-002.v2",
+  "currentTaskId": null,
+  "activePhase": null,
+  "tasks": [
+    {
+      "id": "T001",
+      "title": "[TEST] Add failing tests for duplicate and over-limit row outcomes",
+      "type": "TEST",
+      "phase": 1,
+      "parallel": false,
+      "dependsOn": [],
+      "touches": ["bulk-invite-rules"],
+      "files": ["src/invite/bulk-import.test.ts"],
+      "run": ["npm test -- src/invite/bulk-import.test.ts"],
+      "checks": ["tests fail before implementation"],
+      "acceptance": ["dangerous row outcomes are reproduced as explicit failing tests"],
+      "verification": ["npm test -- src/invite/bulk-import.test.ts"],
+      "evidence": ["failing test output"],
+      "context": {
+        "readFiles": ["design.md", "tasks.md", "src/invite/bulk-import.ts"],
+        "commands": ["npm test -- src/invite/bulk-import.test.ts"],
+        "notes": ["freeze row semantics before broader execution"]
+      },
+      "reviews": { "spec": "pass", "code": "pass" },
+      "status": "passed",
+      "attempts": 1,
+      "maxRetries": 1
+    },
+    {
+      "id": "T002",
+      "title": "[IMPL] Implement the initial bulk invite row classification",
+      "type": "IMPL",
+      "phase": 1,
+      "parallel": false,
+      "dependsOn": ["T001"],
+      "touches": ["bulk-invite-rules"],
+      "files": ["src/invite/bulk-import.ts"],
+      "run": ["npm test -- src/invite/bulk-import.test.ts"],
+      "checks": ["rule tests pass"],
+      "acceptance": ["bulk invite rows receive deterministic initial states"],
+      "verification": ["npm test -- src/invite/bulk-import.test.ts"],
+      "evidence": ["passing test output", "checkpoint summary"],
+      "context": {
+        "readFiles": ["design.md", "tasks.md", "src/invite/bulk-import.test.ts"],
+        "commands": ["npm test -- src/invite/bulk-import.test.ts"],
+        "notes": ["do not invent partial-failure semantics outside the approved design"]
+      },
+      "reviews": { "spec": "pass", "code": "pass" },
+      "status": "passed",
+      "attempts": 1,
+      "maxRetries": 1
+    },
+    {
+      "id": "T003",
+      "title": "[TEST] Add failing admin panel tests for mixed CSV results",
+      "type": "TEST",
+      "phase": 2,
+      "parallel": false,
+      "dependsOn": ["T002"],
+      "touches": ["admin-bulk-invite-ui"],
+      "files": ["src/admin/BulkInvitePanel.test.tsx"],
+      "run": ["npm test -- src/admin/BulkInvitePanel.test.tsx"],
+      "checks": ["admin panel tests fail before UI integration"],
+      "acceptance": ["mixed row outcomes are visible as UI failures before implementation"],
+      "verification": ["npm test -- src/admin/BulkInvitePanel.test.tsx"],
+      "evidence": ["failing test output"],
+      "context": {
+        "readFiles": ["design.md", "tasks.md", "src/admin/BulkInvitePanel.tsx"],
+        "commands": ["npm test -- src/admin/BulkInvitePanel.test.tsx"],
+        "notes": ["UI must not hide ambiguous row states"]
+      },
+      "reviews": { "spec": "pass", "code": "pass" },
+      "status": "passed",
+      "attempts": 1,
+      "maxRetries": 1
+    },
+    {
+      "id": "T004",
+      "title": "[IMPL] Render bulk invite results in the admin panel",
+      "type": "IMPL",
+      "phase": 2,
+      "parallel": false,
+      "dependsOn": ["T003"],
+      "touches": ["admin-bulk-invite-ui"],
+      "files": ["src/admin/BulkInvitePanel.tsx"],
+      "run": ["npm test -- src/admin/BulkInvitePanel.test.tsx"],
+      "checks": ["admin panel tests pass"],
+      "acceptance": ["admins can see accepted, skipped, and rejected rows in the panel"],
+      "verification": ["npm test -- src/admin/BulkInvitePanel.test.tsx"],
+      "evidence": ["passing test output", "review notes"],
+      "context": {
+        "readFiles": ["design.md", "tasks.md", "src/admin/BulkInvitePanel.test.tsx"],
+        "commands": ["npm test -- src/admin/BulkInvitePanel.test.tsx"],
+        "notes": ["surface row states without redefining backend truth"]
+      },
+      "reviews": { "spec": "pass", "code": "pass" },
+      "status": "passed",
+      "attempts": 1,
+      "maxRetries": 1
+    },
+    {
+      "id": "T005",
+      "title": "Run mixed-surface checks and gather review evidence",
+      "type": "OTHER",
+      "phase": 3,
+      "parallel": false,
+      "dependsOn": ["T004"],
+      "touches": ["quality-gates"],
+      "files": ["src/admin/BulkInvitePanel.tsx", "src/invite/bulk-import.ts"],
+      "run": [
+        "npm test -- src/invite/bulk-import.test.ts",
+        "npm test -- src/admin/BulkInvitePanel.test.tsx"
+      ],
+      "checks": ["targeted tests pass", "review evidence collected"],
+      "acceptance": ["fresh verification evidence exists for cc-check"],
+      "verification": [
+        "npm test -- src/invite/bulk-import.test.ts",
+        "npm test -- src/admin/BulkInvitePanel.test.tsx"
+      ],
+      "evidence": ["passing targeted test output", "review notes"],
+      "context": {
+        "readFiles": ["tasks.md", "task-manifest.json"],
+        "commands": [
+          "npm test -- src/invite/bulk-import.test.ts",
+          "npm test -- src/admin/BulkInvitePanel.test.tsx"
+        ],
+        "notes": ["fresh evidence can still block if the design contract is incomplete"]
+      },
+      "reviews": { "spec": "pass", "code": "pass" },
+      "status": "passed",
+      "attempts": 1,
+      "maxRetries": 1
+    }
+  ],
+  "metadata": {
+    "source": "tasks.md",
+    "generatedBy": "docs-example",
+    "planVersion": 1
+  }
+}