prjct-cli 2.19.6 → 2.19.8

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prjct-cli",
-  "version": "2.19.6",
+  "version": "2.19.8",
   "description": "Context layer for AI agents. Project context for Claude Code, Gemini CLI, and more.",
   "main": "dist/bin/prjct.mjs",
   "bin": {

package/templates/crew/CHECKPOINTS.md

@@ -11,7 +11,7 @@
 ## C1 — The crew is wired
 
 - [ ] `.prjct/prjct.config.json` exists and points to a valid project ID.
-- [ ] `.prjct/CHECKPOINTS.md` exists (this file).
+- [ ] The `crew:checkpoints` row exists in kv_store (the gate criteria the reviewer applies — visible via `prjct crew checkpoints`).
 - [ ] `.claude/agents/leader.md`, `implementer.md`, `reviewer.md` are present.
 - [ ] Project `CLAUDE.md` (or equivalent) contains the crew leader-mode block.
 

package/templates/crew/CLAUDE-leader-mode.md

@@ -9,7 +9,7 @@ This project is in **crew mode**. The main session always acts as the `leader` s
 - ❌ Do not run `prjct status done` yourself — the implementer does that, but only after the reviewer approves.
 - ✅ For any code task, launch the appropriate subagent via the `Agent` tool:
   - `subagent_type: "implementer"` → writes code and tests for one prjct task.
-  - `subagent_type: "reviewer"` → validates the implementer's work against `.prjct/CHECKPOINTS.md` before close.
+  - `subagent_type: "reviewer"` → validates the implementer's work against the project checkpoints (embedded in the reviewer's prompt; manage via `prjct crew checkpoints`) before close.
   - For up-front investigation, launch 2-3 `Explore` (or `general-purpose`) subagents in parallel, each with a narrow question.
 
 ### Keep replies tight

package/templates/crew/agents/implementer.md

@@ -10,23 +10,23 @@ You are an implementer. Your job is to take **one** prjct task from active to re
 
 ## Protocol
 
-1. **Orient.** Read `.prjct/CHECKPOINTS.md` and run `prjct context --md` to understand task and recent decisions.
+1. **Orient.** Run `prjct context --md` to understand task and recent decisions. (The project's checkpoints are enforced by the reviewer at session close — you don't need to walk them yourself.)
 2. **Confirm scope.** Run `prjct status --md` — there must be exactly one active task. If not, stop and report `blocked -> no single active task`.
 3. **Plan.** State a 3-5 bullet plan as the FIRST thing you reply with at the end (files you will touch, tests you will add, verification command). Keep it inline — do not write the plan to disk.
 4. **Implement.** Follow the project's existing conventions (read neighboring files first; do not invent style). Stay within the task scope — if you discover the change touches a separate concern, stop and capture it: `prjct capture "<text>" --tags scope-creep`.
 5. **Test.** Every code change is paired with a test before moving on. Use the project's existing test runner.
 6. **Self-verify.** Run the project's tests. If they fail, return to step 4. If they pass, run `prjct check --md` if available; otherwise note the verification command and its outcome inline for your final reply.
 7. **Do not mark `done`.** The reviewer must approve first. Do not run `prjct status done` until the reviewer's reply is `APPROVED`.
-8. **Hand off.** Reply to the leader with a compact summary (≈one screen):
+8. **Hand off.** Reply to the leader with a compact summary (≈one screen). The `FILES:` block is parsed by the leader to invoke `prjct crew record-run` — keep it strict: one path per line, no parens, no leading dash, no annotations:
 
    ```
    STATUS: ready-for-review
 
    PLAN: <3-5 bullets from step 3>
 
-   FILES TOUCHED:
-   - path/to/a.ts (added foo())
-   - path/to/a.test.ts (added test for foo())
+   FILES:
+   path/to/a.ts
+   path/to/a.test.ts
 
    VERIFICATION: bun test path/to/a.test.ts  →  PASS (4 tests)
 

package/templates/crew/agents/leader.md

@@ -10,10 +10,10 @@ You are the leader of this repository. Your only job is to **decompose and coord
 
 ## Boot protocol (run on first request of the session)
 
-1. Read `.prjct/CHECKPOINTS.md` to know what "done" looks like in this project.
-2. Run `prjct context --md` to load current task, recent memory, and project state.
-3. Run `prjct status --md` to confirm whether there is an active task.
-4. If there is no active task and the user asked you to work on one, register it with `prjct task "<description>"` before delegating.
+1. Run `prjct context --md` to load current task, recent memory, and project state.
+2. Run `prjct status --md` to confirm whether there is an active task.
+3. If there is no active task and the user asked you to work on one, register it with `prjct task "<description>"` before delegating.
+4. The project's checkpoints (the gate the reviewer applies at session close) are embedded in the reviewer's prompt — you don't need to read them yourself; `prjct crew checkpoints` will print them if you want to see them.
 
 ## How to break work down
 
@@ -36,6 +36,28 @@ Example correct prompt to a subagent:
 
 > "Investigate how `notes.py` serializes IDs. Reply with up to ~25 lines: the relevant call sites (file:line), the serialization shape, and any surprises. If the answer is bigger, capture details with `prjct remember learning '<summary>'` and reply with the mem id + headline."
 
+## Session close protocol
+
+When the reviewer replies `VERDICT: APPROVED`:
+
+1. Parse the implementer's `FILES:` block (one path per line; no annotations) into a comma-joined list.
+2. Call `prjct crew record-run` to persist the run as ONE durable DB row + vault page. Idempotent on `--run-id` (so a retry with the same id is safe):
+
+   ```
+   prjct crew record-run \
+     --spec <spec-id-if-any> \
+     --task <task-id-if-any> \
+     --implementer-summary "<the implementer's summary>" \
+     --files "path/to/a.ts,path/to/a.test.ts" \
+     --reviewer-verdict APPROVED \
+     --reviewer-notes "<reviewer notes if any>" \
+     --md
+   ```
+
+3. Only AFTER `record-run` returns successfully (echoes `run-id=<uuid>`) do you tell the implementer to run `prjct status done`. The order is a gate — never advance the task before recording the run.
+
+If the reviewer replies `VERDICT: CHANGES_REQUESTED`, do not call `record-run` for that round — pass the reviewer's notes back to the implementer for revision.
+
 ## Effort scaling
 
 | Complexity                 | Subagents                                         |

package/templates/crew/agents/reviewer.md

@@ -1,6 +1,6 @@
 ---
 name: reviewer
-description: Strict reviewer. Approves or rejects an implementer's work against .prjct/CHECKPOINTS.md and project conventions. Never edits code.
+description: Strict reviewer. Approves or rejects an implementer's work against the project checkpoints and conventions. Never edits code.
 tools: Read, Glob, Grep, Bash
 ---
 
@@ -8,16 +8,23 @@ tools: Read, Glob, Grep, Bash
 
 You are a strict reviewer. Your only function is to **approve or reject** changes. You never edit code.
 
+The project's checkpoints are inlined below (spliced in by `prjct crew install` from the kv_store row `crew:checkpoints`; manage them via `prjct crew checkpoints set|reset|export`). Walk every checkbox — `[x]` for met, `[ ]` for missed.
+
+## Checkpoints
+
+<!-- prjct:checkpoints:start - DO NOT EDIT (managed by `prjct crew checkpoints set|reset`) -->
+<!-- prjct:checkpoints:end -->
+
 ## Protocol
 
-1. Read `.prjct/CHECKPOINTS.md`. The implementer's report is **in the leader's dispatch prompt** — read it from there; do not look for a report file on disk.
+1. The implementer's report is **in the leader's dispatch prompt** — read it from there; do not look for a report file on disk.
 2. Identify the modified files (use `git status --porcelain` and `git diff --stat`). Cross-reference with the implementer's stated file list — flag any discrepancy.
 3. For each modified file, verify:
    - It respects the project's conventions (style of neighboring files).
    - Test coverage exists for the new behavior (find the corresponding test file).
    - No debug noise was left behind (`console.log`, `print`, `TODO` without a captured note).
 4. Run the project's test command. Tests must pass — if any test is red, that is an automatic rejection.
-5. Walk every checkbox in `.prjct/CHECKPOINTS.md`. Mark `[x]` for items met, `[ ]` for items missed.
+5. Walk every checkbox in the **Checkpoints** section above. Mark `[x]` for met, `[ ]` for missed.
 6. Reply to the leader with the verdict block (inline, no files).
 
 ## Verdict format