R89.B λ Phase 2 Staging — Behavioral Contract

Step 2 of 5 in the R89.B 5-step chain. Defines the acceptance contract for the prompt file docs/guides/implementation/task-prompts/p2.1-lambda-reputation.md that Step 4 will author. Gates Step 3 (packet) and Step 4 (implement).

1. Artifact under contract

Field Value
Filename docs/guides/implementation/task-prompts/p2.1-lambda-reputation.md
Type agent-prompts (per task-prompts/index.md)
Pattern source task-prompts/p1.1-kappa-rule-engine.md (R76.P1, refined R83+)
Sub-task count exactly 7 (matches Phase 2 budget in task-breakdown.md §Task Summary)
Sub-task IDs P2.1.1, P2.1.2, P2.2.1, P2.2.2, P2.3.1, P2.4.1, P2.5.1 (no renumbering)
Estimated total length ≥ 700 lines (~100 lines per task entry minimum, plus 100-line file intro)
Target consumer Cold T3 sub-agent dispatched by PM under host Task tool

2. Contract: file intro section

The prompt file’s introduction (before the first sub-task entry) MUST satisfy:

2.1 Frontmatter requirements 

---
title: "P2.1 — λ Reputation — Agent Prompts"
tags: [phase-2, agents, prompts, p2, lambda, reputation, planning]
type: agent-prompts
status: ready
phase: 2
round: R89
updated: 2026-05-12
---

2.2 Required intro subsections (in order)

Subsection Content requirement
H1 title # P2 — λ Reputation — Agent Prompts
Blockquote preamble Mentions: dispatch readiness, “Phase 2 starts at R91” (next round after R89/R90), canonical spec link, concept doc link, master bootstrap link, executor rules link
§Axis goals 1-paragraph statement of what λ is and what shipping it accomplishes
§Design invariants Numbered list (mirror p1.1 §Design invariants) — see §2.3 below
§Dependency map Declares P0 28/28 + κ 20/20 closure; cites the specific upstream paths λ consumes
§Ordering rationale Wave 1 → Wave 4 plan; effort distribution; reasoning for the parallel cap
§Roadmap budget reference Cites task-breakdown.md §Task Summary (line ~1136) Phase 2 row: 7 tasks / 2–3 weeks
§Group summary table Mirror p1.1’s table (Task ID / Title / Depends-on / Effort / Unblocks)

2.3 Required design invariants

Numbered list, MUST include (executor inherits these from κ + adds λ-specific):

  1. 64-bit signed integer arithmetic — no floats anywhere (inherits κ P1.1.1).
  2. Deterministic execution — no RNG / clock / async I/O / network / filesystem in λ computation paths (inherits κ P1.1.2). SHA-256 via crypto.createHash is the only crypto primitive permitted, and only for pattern-matching feature hashes (s05 §Pattern-matching).
  3. Reputation is non-transferable (s04, s05). No code path may copy a reputation row between node_id values.
  4. Token log is append-only (s05 §Append-only vs garbage collection, AX-01). Derived caches may be pruned; the event log is immutable.
  5. Score floor is 0; score ceiling is 10000 - scar_bps per domain. Neither is bypassable.
  6. Scars are permanent (s04 §Permanent scars). A scar row in the schema is never deleted; its weight may be clamped to 0 by arbitration outcome (s05 §Scars supersede; s09 reverses scars only via arbitration appeal).
  7. All penalty applications are rule evaluations, not administrative writes — they flow through the κ rule engine and carry a version hash (reputation.md §Penalty schedule).
  8. Five domains: execution, commissioning, arbitration, governance, social. No sixth domain may be added without a roadmap amendment.
  9. Five token levels in Phase 2: L0, L1, L1.5, L2a, L2b. L3 is deferred to Phase 6 π governance (aggregation across L2b sets — see audit §3 row 3).
  10. All λ computation lives under src/domains/reputation/. The determinism scanner from P1.1.2 must be extended to cover this path.

2.4 Required dependency map

The dependency map MUST cite each of these P0 + κ outputs with its src/ path and the R# that shipped it:

  • src/domains/rules/integer-math.ts (R83 P1.1.1) — bps_mul, bps_div, apply_bps, decay, safe_mul, safe_div
  • src/domains/rules/bps-constants.ts (R83 P1.1.3) — DECAY_*, DAMAGE_*, BPS_* constants
  • src/__tests__/domains/rules/determinism.test.ts (R83 P1.1.2) — extend scanner to src/domains/reputation/**
  • src/domains/rules/engine.ts (R85 P1.3.1) — rule evaluation
  • src/domains/rules/builtins.ts (R86 P1.3.2) — sqrt_floor, log2_floor for derived limits
  • src/domains/rules/admission.ts (R87 P1.4.1) — λ gates piggyback for tool-call eligibility
  • src/domains/skills/ (P0.6.x) — tool registration surface for the 4 reputation_* MCP tools
  • src/domains/tasks/ (P0.3.x) — writeback hard-block enforcement (every P2 task must produce thought_record)
  • src/domains/trail/ (P0.7.x) — thought_record + audit chain
  • src/domains/proof/ (P0.8.x) — Merkle anchoring for proof-grade penalty events

3. Contract: per-task entries

Each of the seven sub-task entries MUST satisfy:

3.1 Header section 

## P2.X.Y — <Title> — Phase 2 λ Wave <N>

**Spec source:** [task-breakdown.md §P2.X.Y](../task-breakdown.md#p2xy--<slug>)
**Concept reference:** `docs/3-world/social/reputation.md` §<relevant section>
**Spec docs:** `docs/spec/s04-reputation.md` §<sect>, `docs/spec/s05-experience-tokens.md` §<sect>, (s09 if applicable)
**Worktree:** `feature/p2-x-y-<slug>`
**Branch command:** `git worktree add .worktrees/claude/p2-x-y-<slug> -b feature/p2-x-y-<slug> origin/main`
**Estimated effort:** <S|M|L>
**Depends on:** <upstream tasks>
**Unblocks:** <downstream tasks>

3.2 Mandatory subsections (in order)

# Subsection Required content
1 ### Files to create Absolute paths under src/domains/reputation/ + corresponding test paths under src/__tests__/domains/reputation/
2 ### Acceptance criteria Markdown checklist; minimum 6 items per task; specific enough that a reviewer can mechanically verify each
3 ### Pre-flight reading Numbered list: CLAUDE.md, task-breakdown.md section, reputation.md section, relevant spec(s), any upstream src/ files consumed
4 ### Ready-to-paste agent prompt Triple-backtick text block containing: TASK title, FILES TO READ FIRST, WORKTREE SETUP, FILES TO CREATE (with file-level commentary), ACCEPTANCE CRITERIA (headline), SUCCESS CHECK (npm run build && npm run lint && npm test), WRITEBACK (full task_update + thought_record template), FORBIDDENS, NEXT
5 ### Verification checklist (for reviewer agent) Bullet list of post-implementation checks
6 ### Writeback template YAML block with task_update + thought_record fields
7 ### Common gotchas 3+ bullet items capturing implementation pitfalls specific to that task

3.3 Entry length floor

Each entry MUST be ≥ 80 lines (per the dispatch prompt explicit requirement). The κ reference (p1.1) averages ~140 lines per entry — that is the target range; 80 is the floor.

3.4 Writeback block requirements

Every Ready-to-paste prompt’s WRITEBACK section MUST:

  • Use canonical thought_record signature: thought_record(session_id, thought_type, content) — not the donor-era task_id-as-keyword form swept out in R88.A
  • Use thought_type="reflection"
  • Use session_id="r91-lambda-phase-2" (placeholder; PM updates at dispatch time)
  • Carry the 6 canonical content lines: task_id, branch, worktree, commit, tests, summary (plus optional blockers)
  • Match the modern signature established by R88.A’s sweep of donor-era templates

3.5 Source line references

Every entry’s Spec source / Concept reference / Spec docs lines MUST be live relative links that resolve from the prompt file’s location (docs/guides/implementation/task-prompts/). Verify by:

  • task-breakdown.md → ../task-breakdown.md
  • reputation.md → ../../../3-world/social/reputation.md
  • s04-reputation.md → ../../../spec/s04-reputation.md
  • s05-experience-tokens.md → ../../../spec/s05-experience-tokens.md
  • s09-arbitration.md → ../../../spec/s09-arbitration.md

4. Contract: spec coverage matrix

The prompt file, taken as a whole, MUST cover every λ surface element catalogued in Step 1 (Audit §2.1–§2.8). The Step 5 verification artifact (r89-b-lambda-phase-2-staging-verification.md) will assert this matrix line-by-line. If any spec element has zero sub-task coverage, Step 4 must add it before Step 5 can sign off.

Coverage matrix (from audit §6, repeated here for contract enforcement):

Surface element Required sub-task(s)
5-domain schema P2.1.1
Per-record fields (score, scars, ban_until, last_activity) P2.1.1
History append-only table P2.1.1
Indexes ((node_id, domain), (domain, score DESC)) P2.1.1
compute_score(node_id, domain, events[]) P2.1.2
BPS-based monotonicity property test P2.1.2
Per-epoch decay (inactive only; per-domain reset) P2.2.1
Score floor at 0 P2.2.1 + P2.1.2
Batch decay (10k+ nodes/epoch) P2.2.1
Severity-band penalty table (minor → fraud) P2.2.2
Scar mechanism (permanent cap reduction) P2.2.2
Ban mechanism (ban_until_epoch) P2.2.2
Double-jeopardy guard P2.2.2
L0 / L1 / L1.5 / L2a / L2b tokens P2.3.1
Token non-transferability P2.3.1
Token append-only event log P2.3.1
Witness registry + independence rule P2.3.1
SHA-256 feature hash + diversity gate + invariance gate P2.3.1
max_parallel_tasks(rep) derived limit P2.4.1
rate_limit_bonus(rep) derived limit P2.4.1
stake_discount(rep) derived limit P2.4.1
can_arbitrate(rep) gate P2.4.1
can_govern(rep) gate P2.4.1
reputation_get MCP tool P2.5.1
reputation_history MCP tool P2.5.1
reputation_leaderboard MCP tool P2.5.1
reputation_check_gates MCP tool P2.5.1

Acceptance: every row above maps to at least one sub-task entry in the authored prompt file. The mapping is verified in Step 5 by inspecting each sub-task’s Acceptance criteria checklist for the row keyword.

5. Contract: cross-document consistency

The prompt file MUST stay consistent with three external surfaces:

  1. task-breakdown.md §Phase 2 — sub-task IDs, dependencies, output paths, and acceptance criteria MUST match. Changes to task-breakdown require a separate doc PR; this prompt file copies, does not redefine.
  2. task-prompts/index.md — when this prompt file lands, the index MUST gain a row in the “Phase 2 Task Prompts” table (added by this PR). Pattern: see §Phase 1 Task Prompts row that points to p1.1-kappa-rule-engine.md. The index update is in scope for Step 4.
  3. docs/3-world/social/reputation.md — current frontmatter is colibri_code: none. The prompt file MUST NOT graduate the frontmatter — graduation happens when λ ships, not when its prompt file is staged (per ADR-006 graduation rules). No frontmatter changes to reputation.md in this PR.

6. Contract: out-of-scope assertions

The prompt file MUST explicitly call out, in the file intro, that the following are OUT OF SCOPE for Phase 2 λ:

  • L3 aggregate tokens (defer to Phase 6 π governance)
  • Quadratic voting math (defer to Phase 6 π; λ exposes only the credit balance read)
  • θ commit-reveal arbiter voting (defer to Phase 3 θ consensus)
  • ξ Soul Vector binding (defer to Phase 7 ξ identity)
  • Cross-fork L3 recomputation (defer to Phase 5 ι fork)
  • Arbitration write-side (panel selection, escalation; defer to Phase 3 θ + Phase 6 π)
  • Reputation transfer or staking (constitutional violation; never implemented)

7. Contract: gate compliance

The Step 4 authored file MUST pass:

  • npm run build — should remain unaffected (docs-only PR); regression = fail
  • npm run lint — markdown lint if configured; regression = fail
  • npm test — full suite must continue to pass at the same count as base fab4bf57; regression = fail and Step 4 must investigate before opening PR

8. Acceptance criteria summary

The prompt file is accepted when:

  • All 7 sub-task entries present, each ≥ 80 lines, each following the §3.2 structure
  • File intro present with all §2.2 subsections
  • Design invariants (10 items) present per §2.3
  • Dependency map cites every entry in §2.4
  • Every spec surface row in §4 maps to ≥ 1 sub-task
  • Frontmatter matches §2.1 exactly
  • All relative links in §3.5 resolve from the prompt file location
  • Out-of-scope assertions per §6 present in intro
  • task-prompts/index.md updated with Phase 2 row (per §5.2)
  • No changes to reputation.md or any spec doc (per §5.3)
  • npm run build && npm run lint && npm test all green (per §7)

R89.B λ Phase 2 Staging Step 2 (Contract) — completed against base fab4bf57.

Back to top

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

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