R89.B λ Phase 2 Staging — Execution Packet

Step 3 of 5 in the R89.B 5-step chain. Gates Step 4 (implement). Defines the ordering rationale + dispatch-ready packet shape for the 7 λ Phase 2 sub-tasks that the authored prompt file will carry.

1. Dispatch packet shape per sub-task

Each of the seven p2.1-lambda-reputation.md entries serves as a complete dispatch packet for a downstream T3 executor. The packet’s READY-TO-PASTE prompt block is the artifact PM will copy verbatim into the host Task tool dispatch.

Per CLAUDE.md §8 Case A (PM → T3) the packet must contain, in order:

  1. TASK title (with Phase + axis context)
  2. FILES TO READ FIRST (CLAUDE.md, task-breakdown.md section, concept doc, specs, upstream src/)
  3. WORKTREE SETUP (git worktree add exact command line)
  4. FILES TO CREATE (with file-level commentary on functions/types/exports)
  5. ACCEPTANCE CRITERIA (headline summary; full list in ### Acceptance criteria subsection above)
  6. SUCCESS CHECK (cd .worktrees/claude/<slug> && npm run build && npm run lint && npm test)
  7. WRITEBACK (full task_update + thought_record block with canonical signature)
  8. FORBIDDENS (3+ negative constraints — no Math, no main checkout, etc.)
  9. NEXT (the immediate downstream sub-task this unblocks)

2. Sub-task DAG 

                        ┌── P2.1.1 (schema; S; foundation; depends on P1.1.1)
                        │
              ┌─────────┼──────────┬──────────┬──────────┐
              ▼         ▼          ▼          ▼          │
       P2.1.2 (M)  P2.2.1 (M)  P2.2.2 (M)  P2.3.1 (L)    │
       score-compute decay     penalties   tokens         │
              │                                           │
              ▼                                           │
       P2.4.1 (M) ◀──────────────── P1.3.2 (kappa builtins)
       derived-limits
              │
              └──────────────────────────────────────────▶┐
                                                          │
                                                          ▼
                                                   P2.5.1 (S)
                                                   MCP tools
                                                   ◀─── P0.3.4 (tool binding)

3. Wave plan

The wave plan follows the κ Phase 1 R87 pattern: 3-parallel maximum per wave; each wave gated on the prior wave’s PR merge.

Wave 1 — Foundation (1 task)

Task Effort Why solo Unblocks
P2.1.1 — Reputation Record Schema S Every other λ task depends on the schema columns + history table. Cannot run alongside the others; nothing else has a valid domain enum or score column to compute on. P2.1.2, P2.2.1, P2.2.2, P2.3.1

Wave gate: P2.1.1 PR merges. PM verifies the schema + migration land cleanly, checks data/colibri.db migration succeeds on a fresh boot, then opens Wave 2.

Wave 2 — Core computation (3 parallel)

Task Effort Notes
P2.1.2 — Score Computation M First-class consumer of P2.1.1 + κ engine.
P2.2.1 — Exponential Decay M Pure function over schema; uses decay() from κ integer-math.
P2.2.2 — Offense Penalties M Pure function over schema + κ damage constants.

Why 3-parallel: all three share P2.1.1 as the sole dependency and produce non-overlapping output paths (compute.ts, decay.ts, penalties.ts). Each carries its own test file under src/__tests__/domains/reputation/. Zero merge conflict surface.

Deferred to Wave 3: P2.3.1 (Tokens) — although it also depends only on P2.1.1, it is L effort (the largest in λ) and the dispatch prompt’s 3-parallel ceiling for safety holds. Slot it solo in Wave 3 or alongside P2.4.1 if PM judges the L tokens task is well-scoped enough to run with a smaller-effort partner.

Wave gate: all three PRs merge. PM verifies score / decay / penalty unit tests green; spot-checks the BPS math against the audit’s §3 reconciliation rows; then opens Wave 3.

Wave 3 — Tokens + derived limits (2 parallel, or 1+1 sequential at PM discretion)

Task Effort Notes
P2.3.1 — Token Levels and Minting L Independent surface — own table (experience_tokens), own witness side-table (mcp_witnesses).
P2.4.1 — Capability Gates M Depends on P2.1.2 (score reads). Pure derivation from current scores. Uses sqrt_floor, log2_floor from κ P1.3.2.

Why 2-parallel: P2.3.1 and P2.4.1 share no files. P2.4.1 needs P2.1.2 merged (in Wave 2); P2.3.1 needs only P2.1.1 (in Wave 1) so it could technically run earlier. Slotting both to Wave 3 keeps the dispatch ceiling conservative and aligns with the “L task gets sibling support” pattern.

Wave gate: both PRs merge. PM verifies token-promotion path (L0 → L1 → L1.5) produces the expected feature_hash; verifies derived-limit gates against hand-calculated boundary cases.

Wave 4 — MCP tool surface (1 task)

Task Effort Notes
P2.5.1 — Reputation Query Tools S Read-only tool surface; depends on all preceding λ outputs. Cannot run earlier.

Wave gate: PR merges. λ Phase 2 closed at 7/7. PM updates memory file + opens the colibri_code: partial graduation (separate hygiene PR per ADR-006 rule that graduation happens after ship, not coincident with ship).

4. Total wave count and effort

Wave Tasks Effort sum Wallclock estimate (at R87 dispatch velocity)
1 1 S ~30 min
2 3 3M ~60–90 min (parallel)
3 2 L + M ~90 min (parallel; L drives)
4 1 S ~30 min
Total 7 2S + 4M + 1L ~3–4 hours wallclock at R87 pace

R87 shipped 7 κ tasks across 3 waves in ~1h45m. λ adds an extra wave for the foundation gate and includes one L-effort task, justifying the ~3–4h estimate. Roadmap budget at task-breakdown.md §Task Summary line ~1136 says “2–3 weeks” for the human-paced estimate; R87’s dispatch velocity routinely compresses 1-week roadmap rows to a single session, so 3–4 hours is the realistic AI-paced figure.

5. Per-task file layout (preview for Step 4)

For each sub-task in the prompt file, the FILES TO CREATE block under the Ready-to-paste prompt MUST resolve to:

Sub-task Output files
P2.1.1 src/domains/reputation/schema.ts + src/__tests__/domains/reputation/schema.test.ts + src/db/migrations/<n>-reputation.sql
P2.1.2 src/domains/reputation/compute.ts + src/__tests__/domains/reputation/compute.test.ts
P2.2.1 src/domains/reputation/decay.ts + src/__tests__/domains/reputation/decay.test.ts
P2.2.2 src/domains/reputation/penalties.ts + src/__tests__/domains/reputation/penalties.test.ts
P2.3.1 src/domains/reputation/tokens.ts + src/domains/reputation/witnesses.ts + src/__tests__/domains/reputation/tokens.test.ts + src/__tests__/domains/reputation/witnesses.test.ts + src/db/migrations/<n>-experience-tokens.sql
P2.4.1 src/domains/reputation/limits.ts + src/__tests__/domains/reputation/limits.test.ts
P2.5.1 src/domains/reputation/tools.ts + src/__tests__/domains/reputation/tools.test.ts (+ registration glue in src/server.ts if not auto-discovered through ε)

6. Branch / worktree naming convention

All seven branches follow the κ pattern (lowercased, dashed):

Sub-task Branch Worktree
P2.1.1 feature/p2-1-1-rep-schema .worktrees/claude/p2-1-1-rep-schema
P2.1.2 feature/p2-1-2-score-compute .worktrees/claude/p2-1-2-score-compute
P2.2.1 feature/p2-2-1-decay .worktrees/claude/p2-2-1-decay
P2.2.2 feature/p2-2-2-penalties .worktrees/claude/p2-2-2-penalties
P2.3.1 feature/p2-3-1-tokens .worktrees/claude/p2-3-1-tokens
P2.4.1 feature/p2-4-1-limits .worktrees/claude/p2-4-1-limits
P2.5.1 feature/p2-5-1-tools .worktrees/claude/p2-5-1-tools

7. Writeback signature template (R88.A-compliant)

Every Ready-to-paste prompt block’s WRITEBACK section uses this canonical signature:

WRITEBACK (after success, per CLAUDE.md §7):
task_update(id="P2.X.Y", status="done", progress=100)
thought_record(session_id="r91-lambda-phase-2", thought_type="reflection",
  content="task_id: P2.X.Y
branch: feature/p2-x-y-<slug>
worktree: .worktrees/claude/p2-x-y-<slug>
commit: <SHA>
tests: npm run build && npm run lint && npm test
summary: <one-line description of what shipped>
blockers: <residual risks or 'none'>")

Notes:

  • thought_record takes 3 keyword args (session_id, thought_type, content), matching src/domains/trail/ (P0.7.x) shipped surface. Donor-era variants (thought_record(task_id=...) or session_id as a content line) are forbidden per R88.A sweep.
  • session_id placeholder is r91-lambda-phase-2 — PM updates at actual dispatch time based on the round number that opens Phase 2.
  • task_update is also keyword-arg form per CLAUDE.md §7.

8. Spec-source cross-reference per sub-task

For Step 4, each entry’s Spec docs: header line MUST cite the relevant spec sections:

Sub-task s04 sections s05 sections s09 sections
P2.1.1 §Three domains, §Computation (record fields) — —
P2.1.2 §Computation, §Decay (floor) — —
P2.2.1 §Decay — —
P2.2.2 §Damage table, §Permanent scars §Decay and scar supersession §Arbiter constraints (overturned-decision row only)
P2.3.1 — §Token levels, §Promotion flow, §Witness registry, §Pattern-matching algorithm —
P2.4.1 §Derived limits — §Arbiter selection (eligibility consumed by VRF)
P2.5.1 §Computation (read-side surface) — —

9. Group summary table (preview — to appear in prompt file intro)

Task ID Title Depends on Effort Unblocks
P2.1.1 Reputation Record Schema P1.1.1 S P2.1.2, P2.2.1, P2.2.2, P2.3.1
P2.1.2 Score Computation P2.1.1, P1.3.1 M P2.4.1, P2.5.1
P2.2.1 Exponential Decay P2.1.1, P1.1.1 M P2.5.1
P2.2.2 Offense Penalties P2.1.1, P1.1.1 M P2.5.1
P2.3.1 Experience Tokens (L0–L2b) P2.1.1 L P2.5.1
P2.4.1 Capability Gates (derived limits) P2.1.2, P1.3.2 M P2.5.1
P2.5.1 Reputation Query MCP Tools P2.1.2, P2.2.1, P2.2.2, P2.3.1, P2.4.1, P0.3.4 S — (closes λ Phase 2)

10. Out-of-scope reminder (echoes contract §6)

Every prompt-file intro reminder MUST list:

  • L3 aggregate tokens (Phase 6 π governance)
  • Quadratic voting math (Phase 6 π governance)
  • θ commit-reveal arbiter voting (Phase 3 θ consensus)
  • ξ Soul Vector binding (Phase 7 ξ identity)
  • Cross-fork L3 recomputation (Phase 5 ι fork)
  • Arbitration write-side (Phase 3 θ + Phase 6 π)
  • Reputation transfer / staking (constitutional violation — never)

11. Step 4 execution plan

  1. Create docs/guides/implementation/task-prompts/p2.1-lambda-reputation.md with:
    • Frontmatter per contract §2.1
    • File intro per contract §2.2 (incl. tables from this packet §3, §6, §9)
    • 7 sub-task entries following contract §3 layout
  2. Update docs/guides/implementation/task-prompts/index.md with a Phase 2 row in the “Phase 1 Task Prompts” table (rename header to “Phase 1 & 2 Task Prompts” or add a new “Phase 2 Task Prompts” section — see κ pattern at index.md line ~145).
  3. Run npm run build && npm run lint && npm test from the worktree root.
  4. Commit with feat(...) prefix per CLAUDE.md §6 Step 4 commit template.

12. Step 5 verification plan (preview)

Step 5 produces docs/verification/r89-b-lambda-phase-2-staging-verification.md with:

  • Coverage matrix: every contract §4 row → its sub-task entry’s acceptance criteria
  • Length check: each of 7 entries ≥ 80 lines
  • Link check: every relative link in the prompt file resolves on disk
  • Frontmatter conformance: matches contract §2.1
  • Writeback signature conformance: every WRITEBACK block matches packet §7 template
  • Cross-doc check: task-breakdown.md §Phase 2 sub-task IDs match prompt file
  • Test gate evidence: npm run build && npm run lint && npm test output captured

R89.B λ Phase 2 Staging Step 3 (Packet) — completed against base fab4bf57. Gates Step 4 implementation.

Back to top

Colibri — documentation-first MCP runtime. Apache 2.0 + Commons Clause.

This site uses Just the Docs, a documentation theme for Jekyll.