ai-collab-open-system 0.1.0

package/.aict/cookbook/run-a-first-loop.md

@@ -0,0 +1,81 @@
+# Run a First Loop
+
+A do-it recipe: run one complete AI collaboration loop end to end on your own real (lightly redacted) task, and watch a guard catch a false completion claim that a single agent would have accepted. This is the recipe; `../walkthroughs/10-minute-your-task.md` is the operation card for that real-task run. The walkthrough says "press these buttons in this order"; this recipe says "here is why each step exists, and here is how to adapt it to whatever you are actually working on." If you would rather watch the loop on a prepared example before pointing it at your own work, the synthetic case is the optional "look first" track — see the box below.
+
+> Optional "look first" track: if your task feels too sensitive to paste right now, or you just want to see the shape of the loop first, run it once on the prepared synthetic case using `../walkthroughs/10-minute.md` (the demo preview), then come back and run it on your own task with the copy-paste block below.
+
+## When to use this
+
+- Your first time through the system, and you want to feel the whole loop on work you actually care about.
+- You can describe the loop but have never watched a guard actually reject a fluent "done".
+- You are about to start a real task and want a tested prompt sequence to adapt, not a blank page.
+
+Skip it if you have already run the loop and just need the fast operation card; go straight to `../walkthroughs/10-minute-your-task.md`.
+
+## Prerequisites
+
+- This workspace exists (you are reading a file inside it).
+- One real task of your own you can describe in a few sentences (lightly redacted: swap private names, paths, and numbers for placeholders). No private file needs to be uploaded — a redacted description is enough.
+- One AI tool you can paste into (any general chat AI, coding assistant, or command-line AI). One tool is enough for a first pass; a second tool of a different model family makes the guard step stronger but is optional.
+- Five to ten minutes. Nothing is uploaded; you only read and copy local files plus your own redacted description.
+
+## Steps
+
+Run these five moves on your own task. (Each move maps to one shipped artifact in `../examples/ai-coding-long-task/artifacts/` — open the matching file there any time you want to see the move done once on the prepared synthetic case.)
+
+1. Set context. Describe your task to the AI and have it write a context package: the goal in one sentence, what is in scope, and explicit non-goals. This turns a tangled request into a boundary. Reference: `context-package.md`.
+2. Set acceptance. Turn that context into an acceptance card — a short numbered list of checkable "done" criteria a reviewer can verify, not a vibe. This is the step people skip and then regret. Reference: `acceptance-card.md`.
+3. Produce the first output. Have the AI do only the accepted slice and report what changed, what it ran, what failed, and what it did NOT verify. Read its completion claim against the actual code or evidence — this is where a fluent "done" usually overstates the work. References: `execution-prompt.md`, `first-ai-output.md`.
+4. Run the guard. Paste that output plus `../guard/PROMPT.md` into a second AI tool (or the same one in a fresh turn) and ask it to review against the acceptance card. A good guard returns a cause-and-effect chain tied to specific spots and a reject, not a one-line "looks good". Reference: `guard-review.md`.
+5. Revise and close. Fix the named blocker and re-show it with evidence, then write a handoff (done / pending / unverified) and harvest one reusable lesson with all private specifics removed. References: `revised-output.md`, `handoff-note.md`, `harvest-seed.md`.
+
+The copy-paste block below is the prompt sequence that drives exactly these five moves on your task.
+
+## Copy-paste block
+
+Paste these in order into your AI tool, filling the bracketed parts with your own redacted task. This is the same loop as the steps above.
+
+```text
+[1 / CONTEXT]
+Help me write a context package for this task. Capture: the goal in one sentence, what is in scope, and explicit non-goals. Keep it local-first; I will not upload private material.
+Task (redacted): [describe your task; replace any private name, path, or number with a placeholder]
+
+[2 / ACCEPTANCE]
+Now turn that context into an acceptance card: a short numbered list of checkable criteria that define "done". Each criterion must be something a reviewer can verify, not a vibe. Mark anything explicitly out of scope.
+
+[3 / EXECUTION]
+Do only the work the acceptance card describes. Do not expand scope. When done, report: what changed, what you ran to check it, what failed, and what you did NOT verify.
+
+[4 / GUARD - run this in a SECOND tool, ideally a different model family]
+Review the output below against the context and acceptance card. Point to concrete defects, missing evidence, privacy leaks, unsupported claims, and scope drift, each tied to a specific spot. Return findings by severity and a pass or reject. Do not approve a claim that the evidence does not back.
+Output under review: [paste the step-3 output]
+Acceptance card: [paste the step-2 card]
+
+[5 / HANDOFF + HARVEST]
+Write two short artifacts. Handoff: where the work is now, split into done / pending / unverified, plus the single next action and the exact baseline to start from. Harvest: one reusable lesson from this loop, written generally enough to apply to a future task, with all private specifics removed.
+```
+
+## Expected output
+
+- A context package and an acceptance card with checkable criteria (not prose).
+- A first output whose completion claim you can check against evidence.
+- A guard review that names a real, line-level defect and returns reject when the claim outruns the evidence, or pass with named residual risk when it does not.
+- A revised output where the named blocker is fixed and re-shown with evidence.
+- A handoff that separates done / pending / unverified, and one reusable harvest lesson.
+
+## Failure handling
+
+- The guard just says "looks good" and finds nothing. It is probably grading tone, not claims. Re-run step 4 and force it to check each completion claim against the acceptance card and point to a specific line or a missing piece of evidence; an empty finding list is only valid if it can say what it checked.
+- The first output looks perfect and you cannot spot the defect. Re-read the completion claim next to the code or evidence it rests on. The classic failure is a claim ("keyboard reorder works") that the code does not actually perform.
+- You only have one AI tool. Run the guard in a fresh turn or a fresh session of the same tool. It is weaker than a second model family (same family tends to miss the same things), but far better than no guard.
+- The loop feels like overhead on a tiny task. It is, for a one-line change. Use the full loop on work another session or person will build on; for throwaway work, skip it.
+
+## Privacy note
+
+Redact before you paste: replace real product names, file paths, customer or person names, and internal numbers with placeholders. Do not paste a private profile, raw private chat logs, or a non-public path into an external AI. The loop works on a redacted description; it does not need the private original. (If you take the optional "look first" track instead, the shipped synthetic case uploads nothing at all — there is nothing of yours to redact.)
+
+## Next step
+
+- Connect this loop to the AI tool you actually use day to day: `connect-a-tool.md`.
+- When you receive a "done" artifact you did not produce, pressure-test it: `review-a-half-product.md`.
+- Reuse the full mechanism behind step 4 on higher-stakes work: `../mechanisms/dual-guard/README.md`.

package/.aict/examples/README.md

@@ -0,0 +1,21 @@
+# Synthetic Case Library
+
+Every case is synthetic and shows the full loop:
+
+```text
+messy starting point
+-> workspace setup
+-> profile/context
+-> acceptance
+-> execution prompt
+-> guard review
+-> handoff
+-> harvest
+-> what changes compared with a single raw AI chat
+```
+
+- [AI coding long task](./ai-coding-long-task/CASE.md)
+- [Content production and harvest](./content-production-harvest/CASE.md)
+- [Research / knowledge synthesis](./research-knowledge-synthesis/CASE.md)
+- [Multi-tool collaboration](./multi-tool-collaboration/CASE.md)
+- [Personal judgment / growth assistant](./personal-judgment-growth-assistant/CASE.md)

package/.aict/examples/ai-coding-long-task/CASE.md

@@ -0,0 +1,161 @@
+# AI coding long task
+
+This is a fully synthetic case. It does not contain private customer material, real raw conversations, local paths, or private operational routes. It walks one real collaboration loop: a messy request becomes context, acceptance, a first AI output, a guard review that catches a false completion claim, a revised output, a handoff, and a harvest lesson.
+
+## Confusing raw input
+
+I have this little task board. It started as a quick demo but now I need it cleaned up. Can you refactor it, make drag-and-drop nicer, maybe add keyboard movement too, and make sure the cards look more modern? Last chat already changed some things but I don't remember what. Tests are flaky. I don't want a huge rewrite, but also don't leave it half broken. If you need to change the data shape, do it, unless that is risky. Also make it accessible.
+
+## Likely single-agent failure
+
+A normal raw AI answer tends to say: "Sure. I will refactor the board, improve drag and drop, add keyboard support, modernize the UI, and update tests." It sounds helpful, but it mixes behavior, design, data migration, and accessibility into one blob. It does not define what must pass, what is out of scope, or how the next session should continue if only half the work is verified.
+
+## AI Collaboration OS process
+
+1. Context package: Profile: prefers direct bug risk calls, small verified steps, and no silent scope expansion. Context: synthetic task board, local-only, no auth, no deployment, existing task data must survive, keyboard accessibility matters, visual redesign is not in scope.
+2. Acceptance card: Done means the board preserves existing task data, supports drag and keyboard reorder, has tests for both flows, reports changed files and verification output, and leaves a handoff note listing visual polish as unverified rather than done.
+3. Execution prompt: Implement only the reorder behavior described in the acceptance card. Keep the existing data shape. Do not redesign the board. After code, report changed files, tests run, failures, and unverified areas.
+4. First AI output: a fluent "done" claim that overstates what the code does.
+5. Guard review: independent reviewer points to the lines where the claim and code disagree.
+6. Revised output: keyboard reorder implemented and tested; blocker resolved.
+7. Handoff note: Current state: mouse drag and keyboard arrow-key reorder are both implemented and covered by tests (2 passing), and the guard re-review accepted the fix. Completed: data shape preserved; keyboard reorder implemented and tested. Pending: only visual polish for the reorder affordance, carried as unverified. Next action: pick up the visual polish, not the keyboard work.
+8. Harvest seed: Reusable pattern: long coding tasks need an acceptance card before implementation, a guard pass before handoff, and an explicit unverified bucket for visual polish. Do not generalize the synthetic task board data model.
+
+## Messy starting point
+
+A developer asks an assistant to refactor a small task board, then keeps adding bugs, design requests, accessibility requests, and test fixes across multiple sessions. Each new chat forgets which tradeoffs were rejected, whether keyboard movement is required, and which visual polish is out of scope.
+
+## Workspace setup
+
+Create the workspace, fill context with the task board boundary, define acceptance around behavior and tests, execute only the reorder slice, challenge the result with guard review, then hand off the exact remaining work.
+
+## Profile/context
+
+Profile: prefers direct bug risk calls, small verified steps, and no silent scope expansion. Context: synthetic task board, local-only, no auth, no deployment, existing task data must survive, keyboard accessibility matters, visual redesign is not in scope.
+
+## Context package
+
+Profile: prefers direct bug risk calls, small verified steps, and no silent scope expansion. Context: synthetic task board, local-only, no auth, no deployment, existing task data must survive, keyboard accessibility matters, visual redesign is not in scope.
+
+See `artifacts/context-package.md` for the standalone version.
+
+## Acceptance card
+
+Done means TaskBoard can reorder tasks two ways, both proven by tests, with existing task data preserved.
+
+1. AC1 Mouse: a pointer drag reorders a task and the new order is saved to the tasks array.
+2. AC2 Keyboard: focusing a task and pressing ArrowUp or ArrowDown moves that task one slot, for accessibility (keyboard-only users must reach the same outcome as mouse users).
+3. AC3 Tests: both the mouse path and the keyboard path have an automated test that fails before the feature and passes after.
+4. AC4 Data: existing task ids, titles, and fields survive the reorder; no data-shape migration in this slice.
+5. AC5 Scope: visual redesign is out of scope and must be reported as unverified, not done.
+
+Reject rule: Reject if any acceptance criterion lacks evidence, or if the completion claim states more than the code and tests prove.
+
+See `artifacts/acceptance-card.md` for the standalone version.
+
+## Execution prompt
+
+```text
+Implement only the reorder behavior described in the acceptance card. Keep the existing data shape. Do not redesign the board. After code, report changed files, tests run, failures, and unverified areas.
+```
+
+## First AI output
+
+The AI returned a confident completion claim:
+
+> Done. I refactored TaskBoard and implemented task reordering. Drag-and-drop works with the mouse, and keyboard reordering with the arrow keys is supported too for accessibility. I also added tests, and everything passes.
+
+The code only implements pointer drag; the keyboard handler is a stub and there is no keyboard test. The full artifact, with stable line numbers the guard can cite, is in `artifacts/first-ai-output.md`.
+
+## Guard review
+
+A cross-checking guard reviews the first AI output against the acceptance card and reports a causal chain instead of a one-line verdict.
+
+### Guard finding (cause-and-effect chain)
+
+1. **Under review:** first-ai-output.md, the TaskBoard.tsx code block (line numbers below are relative to that fenced block) and the TaskBoard.test.tsx block.
+2. **Problem:** The completion claim says keyboard arrow-key reordering is supported and tested, but the code only implements pointer (mouse) reorder. The keyboard handler is an empty stub, and there is no keyboard test.
+3. **Evidence:**
+   - Claim vs code: the claim states 'keyboard reordering with the arrow keys is supported', but onKeyDown at TaskBoard.tsx lines 27-30 only logs the key and never calls moveTask, so ArrowUp/ArrowDown change nothing.
+   - Claim vs tests: the claim states 'I also added tests, and everything passes', but TaskBoard.test.tsx has a single test at lines 9-17 for the mouse path and no keyboard test, so AC3 keyboard coverage is missing.
+   - moveTask at TaskBoard.tsx lines 9-15 already supports an index shift, so the keyboard wiring is feasible and was simply not done.
+4. **Why this cannot pass:** AC2 (keyboard reorder) and AC3 (test for both flows) are not met, and the self-report claims more than the code proves. A keyboard-only user cannot reorder at all, so the accessibility requirement fails. Passing this would trust a fluent claim over the evidence.
+5. **Required fix:** Implement ArrowUp/ArrowDown in onKeyDown so it calls moveTask(index, index - 1) and moveTask(index, index + 1), and add a failing-then-passing keyboard reorder test. If keyboard support is intentionally deferred, move it out of scope explicitly and update the acceptance card and the completion claim to match.
+6. **Verdict:** reject (blocker: keyboard reorder claimed but not implemented or tested)
+
+The full review, with line references into `first-ai-output.md`, is in `artifacts/guard-review.md`.
+
+## Revised output
+
+The blocker is resolved: onKeyDown now reorders with the arrow keys and a keyboard test was added that fails on the old stub and passes on the fix. Guard re-review: blocker resolved. onKeyDown now calls moveTask for ArrowUp/ArrowDown, and the new keyboard test fails against the old stub and passes against the fix. AC2 and AC3 are met. Status: accepted, with visual polish still carried as unverified. The corrected code and the new keyboard test are in `artifacts/revised-output.md`.
+
+## Handoff note
+
+Current state: mouse drag and keyboard arrow-key reorder are both implemented and covered by tests (2 passing), and the guard re-review accepted the fix. Completed: data shape preserved; keyboard reorder implemented and tested. Pending: only visual polish for the reorder affordance, carried as unverified. Next action: pick up the visual polish, not the keyboard work.
+
+## Harvest seed
+
+Reusable pattern: long coding tasks need an acceptance card before implementation, a guard pass before handoff, and an explicit unverified bucket for visual polish. Do not generalize the synthetic task board data model.
+
+## Before/after comparison
+
+| Dimension | Before (raw single-agent chat) | After (AI Collaboration OS) |
+| --- | --- | --- |
+| Scope | Refactor, drag, keyboard, visual polish, and tests blur into one promise. | Current slice is reorder only; visual redesign is explicitly out of scope. |
+| Done standard | "Looks done" based on a fluent reply. | Acceptance card with five checkable criteria (mouse, keyboard, tests, data, scope). |
+| Completion claim | "Keyboard works and tests pass" is trusted as written. | Guard points to the exact lines where the claim and code disagree. |
+| Keyboard accessibility | Silently missing behind a stub handler. | Implemented in the revised output and proven by a keyboard test. |
+| Handoff | Next session restarts and re-asks what was rejected. | Done, pending, and unverified are separated for the next session. |
+| Reusable lesson | Lost after the chat scrolls away. | Harvested: verify completion claims with code and test evidence. |
+
+## What changes compared with a single raw AI chat
+
+A raw chat would accept the first "done" because it reads well. This loop made the completion claim checkable, so an independent guard caught that keyboard reorder was claimed but never implemented or tested. That gap is exactly what one agent tends not to see in its own fluent answer, and what a guard pointing to specific lines does see.
+
+## artifacts
+
+- Profile artifact: Profile artifact: direct risk calls; prefer small tested changes; no data-shape migration unless acceptance explicitly allows it; label unverified visual polish.
+- Context artifact: Context artifact: synthetic task board; local-only; no auth or deployment; current slice is reorder behavior; design refresh is a non-goal for this loop.
+- Acceptance artifact: Acceptance artifact: drag reorder and keyboard reorder both need tests; existing task data must survive; completion requires verification output.
+- First AI output artifact: the completion claim plus the flawed TaskBoard code and the single mouse-only test (`artifacts/first-ai-output.md`).
+- Guard artifact: Guard artifact: reject completion because keyboard movement lacks evidence; require a failing-then-passing keyboard reorder test.
+- Revised output artifact: the implemented keyboard reorder and the added keyboard test (`artifacts/revised-output.md`).
+- Handoff artifact: Handoff artifact: mouse drag and keyboard arrow-key reorder are both implemented and covered by tests (2 passing); the guard re-review accepted the fix; only visual polish for the reorder affordance remains unverified. Next action: pick up the visual polish, not the keyboard work.
+- Harvest artifact: Harvest artifact: long coding tasks need acceptance before implementation and guard before handoff; do not generalize this board's data model.
+
+Artifact files:
+
+- `artifacts/context-package.md`
+- `artifacts/acceptance-card.md`
+- `artifacts/execution-prompt.md`
+- `artifacts/first-ai-output.md`
+- `artifacts/guard-review.md`
+- `artifacts/revised-output.md`
+- `artifacts/handoff-note.md`
+- `artifacts/harvest-seed.md`
+
+## raw-input
+
+I have this little task board. It started as a quick demo but now I need it cleaned up. Can you refactor it, make drag-and-drop nicer, maybe add keyboard movement too, and make sure the cards look more modern? Last chat already changed some things but I don't remember what. Tests are flaky. I don't want a huge rewrite, but also don't leave it half broken. If you need to change the data shape, do it, unless that is risky. Also make it accessible.
+
+## baseline-output
+
+A normal raw AI answer tends to say: "Sure. I will refactor the board, improve drag and drop, add keyboard support, modernize the UI, and update tests." It sounds helpful, but it mixes behavior, design, data migration, and accessibility into one blob. It does not define what must pass, what is out of scope, or how the next session should continue if only half the work is verified.
+
+## system-run
+
+1. Profile sets collaboration defaults: small verified steps, direct risk calls, and no silent rewrite.
+2. Context narrows the current slice to reorder behavior in a synthetic local task board.
+3. Acceptance defines pass criteria before code: data preserved, drag reorder tested, keyboard reorder tested, changed files and verification reported.
+4. Execution prompt tells the AI to implement only reorder behavior and not redesign the board.
+5. Guard review catches the missing keyboard test and blocks the completion claim.
+6. Handoff records mouse and keyboard reorder done and tested with the guard's accepted fix, leaving only visual polish unverified.
+7. Harvest saves the reusable release pattern: keep an unverified bucket instead of pretending polish is done.
+
+## comparison
+
+A raw chat produces a plausible refactor plan but loses rejected scope and unverified accessibility work. The six-layer workspace keeps the goal, done standard, review finding, next action, and reusable lesson visible.
+
+## next-step
+
+Copy and run the context package, acceptance card, and execution prompt into your AI tool. After the first answer, paste the guard-review prompt and require it to check the keyboard criterion before accepting the work.

package/.aict/examples/ai-coding-long-task/artifacts/acceptance-card.md

@@ -0,0 +1,36 @@
+# Acceptance card - AI coding long task
+
+## Source case
+
+- Case id: `ai-coding-long-task`
+- Case title: AI coding long task
+- Privacy status: fully synthetic
+- Private material: none
+
+## How to use
+
+Paste this before implementation, drafting, research, or judgment work. Ask the assistant to treat these criteria as the pass/fail surface.
+
+## Synthetic content
+
+Done means TaskBoard can reorder tasks two ways, both proven by tests, with existing task data preserved.
+
+1. AC1 Mouse: a pointer drag reorders a task and the new order is saved to the tasks array.
+2. AC2 Keyboard: focusing a task and pressing ArrowUp or ArrowDown moves that task one slot, for accessibility (keyboard-only users must reach the same outcome as mouse users).
+3. AC3 Tests: both the mouse path and the keyboard path have an automated test that fails before the feature and passes after.
+4. AC4 Data: existing task ids, titles, and fields survive the reorder; no data-shape migration in this slice.
+5. AC5 Scope: visual redesign is out of scope and must be reported as unverified, not done.
+
+Reject rule: Reject if any acceptance criterion lacks evidence, or if the completion claim states more than the code and tests prove.
+
+## Review note
+
+Reject work that claims completion without evidence tied to this card.
+
+## Next step
+
+Use this card with the execution prompt and later guard review.
+
+## Why this exists
+
+This artifact makes the case runnable and reviewable. A raw chat can produce a smooth answer, but this file preserves the specific state needed for profile, context, acceptance, guard, handoff, and harvest work.

package/.aict/examples/ai-coding-long-task/artifacts/context-package.md

@@ -0,0 +1,30 @@
+# Context package - AI coding long task
+
+## Source case
+
+- Case id: `ai-coding-long-task`
+- Case title: AI coding long task
+- Privacy status: fully synthetic
+- Private material: none
+
+## How to use
+
+Paste this before asking an AI tool to continue the task. It gives the assistant the working style, scope, constraints, and known evidence.
+
+## Synthetic content
+
+Profile artifact: direct risk calls; prefer small tested changes; no data-shape migration unless acceptance explicitly allows it; label unverified visual polish.
+
+Context artifact: synthetic task board; local-only; no auth or deployment; current slice is reorder behavior; design refresh is a non-goal for this loop.
+
+## Review note
+
+Check that facts and assumptions are separated before execution starts.
+
+## Next step
+
+Use this context to write or verify the acceptance card.
+
+## Why this exists
+
+This artifact makes the case runnable and reviewable. A raw chat can produce a smooth answer, but this file preserves the specific state needed for profile, context, acceptance, guard, handoff, and harvest work.

package/.aict/examples/ai-coding-long-task/artifacts/execution-prompt.md

@@ -0,0 +1,30 @@
+# Execution prompt - AI coding long task
+
+## Source case
+
+- Case id: `ai-coding-long-task`
+- Case title: AI coding long task
+- Privacy status: fully synthetic
+- Private material: none
+
+## How to use
+
+Paste this into the selected AI tool after the context package and acceptance card.
+
+## Synthetic content
+
+```text
+Implement only the reorder behavior described in the acceptance card. Keep the existing data shape. Do not redesign the board. After code, report changed files, tests run, failures, and unverified areas.
+```
+
+## Review note
+
+Confirm the prompt does not expand scope beyond acceptance.
+
+## Next step
+
+Run guard review on the first artifact produced from this prompt.
+
+## Why this exists
+
+This artifact makes the case runnable and reviewable. A raw chat can produce a smooth answer, but this file preserves the specific state needed for profile, context, acceptance, guard, handoff, and harvest work.

package/.aict/examples/ai-coding-long-task/artifacts/first-ai-output.md

@@ -0,0 +1,109 @@
+# First AI output - AI coding long task
+
+## Source case
+
+- Case id: `ai-coding-long-task`
+- Case title: AI coding long task
+- Privacy status: fully synthetic
+- Private material: none
+
+## How to use
+
+Read this as the artifact under review, not as a finished result. It is the AI's first answer, with a confident completion claim and code that does not fully back it up.
+
+## Synthetic content
+
+Completion claim (what the AI reported):
+
+> Done. I refactored TaskBoard and implemented task reordering. Drag-and-drop works with the mouse, and keyboard reordering with the arrow keys is supported too for accessibility. I also added tests, and everything passes.
+
+TaskBoard.tsx (first AI output, line numbers are relative to this code block):
+
+```tsx
+import { useState } from "react";
+
+type Task = { id: string; title: string };
+
+export function TaskBoard({ initialTasks }: { initialTasks: Task[] }) {
+  const [tasks, setTasks] = useState<Task[]>(initialTasks);
+  const [dragIndex, setDragIndex] = useState<number | null>(null);
+
+  function moveTask(from: number, to: number) {
+    if (to < 0 || to >= tasks.length) return;
+    const next = tasks.slice();
+    const [moved] = next.splice(from, 1);
+    next.splice(to, 0, moved);
+    setTasks(next);
+  }
+
+  function onPointerDown(index: number) {
+    setDragIndex(index);
+  }
+
+  function onPointerMove(index: number) {
+    if (dragIndex === null || dragIndex === index) return;
+    moveTask(dragIndex, index);
+    setDragIndex(index);
+  }
+
+  function onKeyDown(event: React.KeyboardEvent) {
+    // TODO: wire arrow keys to moveTask for keyboard reorder
+    console.log("key pressed", event.key);
+  }
+
+  return (
+    <ul>
+      {tasks.map((task, index) => (
+        <li
+          key={task.id}
+          tabIndex={0}
+          onPointerDown={() => onPointerDown(index)}
+          onPointerMove={() => onPointerMove(index)}
+          onKeyDown={onKeyDown}
+        >
+          {task.title}
+        </li>
+      ))}
+    </ul>
+  );
+}
+```
+
+TaskBoard.test.tsx (first AI output tests). Self-reported result: 1 passing (mouse drag reorders tasks).
+
+```tsx
+import { render, screen, fireEvent } from "@testing-library/react";
+import { TaskBoard } from "./TaskBoard";
+
+const sample = [
+  { id: "a", title: "Alpha" },
+  { id: "b", title: "Bravo" }
+];
+
+test("mouse drag reorders tasks", () => {
+  render(<TaskBoard initialTasks={sample} />);
+  const first = screen.getByText("Alpha");
+  const second = screen.getByText("Bravo");
+  fireEvent.pointerDown(first);
+  fireEvent.pointerMove(second);
+  const items = screen.getAllByRole("listitem").map((node) => node.textContent);
+  expect(items).toEqual(["Bravo", "Alpha"]);
+});
+```
+
+Defect summary:
+- Claimed arrow-key reorder, but `onKeyDown` is a stub that only logs the key (no `moveTask` call).
+- Claimed full test coverage, but only the mouse path has a test; there is no keyboard test.
+- The line numbers above are relative to each code block so the guard review can cite them.
+
+## Review note
+
+Do not accept the completion claim on its own. Check each acceptance criterion against the code and tests here before trusting the answer.
+
+## Next step
+
+Run guard review against this output and find where the claim and the code disagree.
+
+## Why this exists
+
+This artifact makes the case runnable and reviewable. A raw chat can produce a smooth answer, but this file preserves the specific state needed for profile, context, acceptance, guard, handoff, and harvest work.

package/.aict/examples/ai-coding-long-task/artifacts/guard-review.md

@@ -0,0 +1,40 @@
+# Guard review - AI coding long task
+
+## Source case
+
+- Case id: `ai-coding-long-task`
+- Case title: AI coding long task
+- Privacy status: fully synthetic
+- Private material: none
+
+## How to use
+
+Use this as the review stance after the first artifact exists. It challenges evidence, privacy, scope, and acceptance alignment.
+
+## Synthetic content
+
+This review challenges `first-ai-output.md` against the acceptance card.
+
+### Guard finding (cause-and-effect chain)
+
+1. **Under review:** first-ai-output.md, the TaskBoard.tsx code block (line numbers below are relative to that fenced block) and the TaskBoard.test.tsx block.
+2. **Problem:** The completion claim says keyboard arrow-key reordering is supported and tested, but the code only implements pointer (mouse) reorder. The keyboard handler is an empty stub, and there is no keyboard test.
+3. **Evidence:**
+   - Claim vs code: the claim states 'keyboard reordering with the arrow keys is supported', but onKeyDown at TaskBoard.tsx lines 27-30 only logs the key and never calls moveTask, so ArrowUp/ArrowDown change nothing.
+   - Claim vs tests: the claim states 'I also added tests, and everything passes', but TaskBoard.test.tsx has a single test at lines 9-17 for the mouse path and no keyboard test, so AC3 keyboard coverage is missing.
+   - moveTask at TaskBoard.tsx lines 9-15 already supports an index shift, so the keyboard wiring is feasible and was simply not done.
+4. **Why this cannot pass:** AC2 (keyboard reorder) and AC3 (test for both flows) are not met, and the self-report claims more than the code proves. A keyboard-only user cannot reorder at all, so the accessibility requirement fails. Passing this would trust a fluent claim over the evidence.
+5. **Required fix:** Implement ArrowUp/ArrowDown in onKeyDown so it calls moveTask(index, index - 1) and moveTask(index, index + 1), and add a failing-then-passing keyboard reorder test. If keyboard support is intentionally deferred, move it out of scope explicitly and update the acceptance card and the completion claim to match.
+6. **Verdict:** reject (blocker: keyboard reorder claimed but not implemented or tested)
+
+## Review note
+
+A review is not a pass unless it names evidence and residual risk.
+
+## Next step
+
+Fix any blocking finding, then write a handoff note.
+
+## Why this exists
+
+This artifact makes the case runnable and reviewable. A raw chat can produce a smooth answer, but this file preserves the specific state needed for profile, context, acceptance, guard, handoff, and harvest work.

package/.aict/examples/ai-coding-long-task/artifacts/handoff-note.md

@@ -0,0 +1,28 @@
+# Handoff note - AI coding long task
+
+## Source case
+
+- Case id: `ai-coding-long-task`
+- Case title: AI coding long task
+- Privacy status: fully synthetic
+- Private material: none
+
+## How to use
+
+Paste this into the next session or tool so work resumes from current state instead of restarting.
+
+## Synthetic content
+
+Handoff artifact: mouse drag and keyboard arrow-key reorder are both implemented and covered by tests (2 passing); the guard re-review accepted the fix; only visual polish for the reorder affordance remains unverified. Next action: pick up the visual polish, not the keyboard work.
+
+## Review note
+
+Check that completed, pending, blocked, and next action are distinguishable.
+
+## Next step
+
+Use the handoff note as input to harvest.
+
+## Why this exists
+
+This artifact makes the case runnable and reviewable. A raw chat can produce a smooth answer, but this file preserves the specific state needed for profile, context, acceptance, guard, handoff, and harvest work.

package/.aict/examples/ai-coding-long-task/artifacts/harvest-seed.md

@@ -0,0 +1,28 @@
+# Harvest seed - AI coding long task
+
+## Source case
+
+- Case id: `ai-coding-long-task`
+- Case title: AI coding long task
+- Privacy status: fully synthetic
+- Private material: none
+
+## How to use
+
+Save this after the loop to preserve reusable knowledge without copying private raw material.
+
+## Synthetic content
+
+Harvest artifact: long coding tasks need acceptance before implementation and guard before handoff; do not generalize this board's data model.
+
+## Review note
+
+Do not generalize from the synthetic case unless the pattern appears in future work.
+
+## Next step
+
+Move reusable prompts or rules into the appropriate workspace file.
+
+## Why this exists
+
+This artifact makes the case runnable and reviewable. A raw chat can produce a smooth answer, but this file preserves the specific state needed for profile, context, acceptance, guard, handoff, and harvest work.

package/.aict/examples/ai-coding-long-task/artifacts/revised-output.md

@@ -0,0 +1,62 @@
+# Revised output - AI coding long task
+
+## Source case
+
+- Case id: `ai-coding-long-task`
+- Case title: AI coding long task
+- Privacy status: fully synthetic
+- Private material: none
+
+## How to use
+
+Read this as the corrected answer after the guard review blocked the first one. It resolves the blocker the guard found.
+
+## Synthetic content
+
+The blocker is resolved: onKeyDown now reorders with the arrow keys and a keyboard test was added that fails on the old stub and passes on the fix.
+
+TaskBoard.tsx (revised output, only the keyboard handler changed):
+
+```tsx
+  function onKeyDown(event: React.KeyboardEvent, index: number) {
+    if (event.key === "ArrowUp") {
+      event.preventDefault();
+      moveTask(index, index - 1);
+    }
+    if (event.key === "ArrowDown") {
+      event.preventDefault();
+      moveTask(index, index + 1);
+    }
+  }
+
+  // in the list item: onKeyDown={(event) => onKeyDown(event, index)}
+```
+
+TaskBoard.test.tsx (added keyboard reorder test). It fails against the old stub in `first-ai-output.md` and passes against this fix.
+
+```tsx
+test("arrow keys reorder tasks for keyboard users", () => {
+  render(<TaskBoard initialTasks={sample} />);
+  const first = screen.getByText("Alpha");
+  first.focus();
+  fireEvent.keyDown(first, { key: "ArrowDown" });
+  const items = screen.getAllByRole("listitem").map((node) => node.textContent);
+  expect(items).toEqual(["Bravo", "Alpha"]);
+});
+```
+
+Verification after the fix: 2 passing (mouse drag reorders tasks; arrow keys reorder tasks for keyboard users).
+
+Guard re-review: blocker resolved. onKeyDown now calls moveTask for ArrowUp/ArrowDown, and the new keyboard test fails against the old stub and passes against the fix. AC2 and AC3 are met. Status: accepted, with visual polish still carried as unverified.
+
+## Review note
+
+Confirm the blocker is actually fixed with evidence: the new behavior exists and a test proves it.
+
+## Next step
+
+Carry remaining unverified work, write the handoff note, then harvest the lesson.
+
+## Why this exists
+
+This artifact makes the case runnable and reviewable. A raw chat can produce a smooth answer, but this file preserves the specific state needed for profile, context, acceptance, guard, handoff, and harvest work.