R89.B λ Phase 2 Staging — Verification

Step 5 of 5 in the R89.B 5-step chain. Asserts the authored prompt file (docs/guides/implementation/task-prompts/p2.1-lambda-reputation.md) satisfies every clause of the Step 2 contract and the Step 3 packet. Includes the spec→sub-task coverage matrix (audit §6 promise).

1. Artifact under verification

Field Value
Prompt file docs/guides/implementation/task-prompts/p2.1-lambda-reputation.md
Line count 1286
Sub-task count 7
Branch feature/r89-b-lambda-phase-2-staging
Base fab4bf57
Commits in chain 5 (1 audit + 1 contract + 1 packet + 1 implement + 1 verify)

2. Sub-task entry presence + length check (contract §3.3 floor: 80 lines)

Sub-task Start line End line Length ≥ 80 lines?
P2.1.1 — Reputation Record Schema 130 277 148 YES
P2.1.2 — Score Computation 278 432 155 YES
P2.2.1 — Exponential Decay 433 581 149 YES
P2.2.2 — Offense Penalties 582 747 166 YES
P2.3.1 — Experience Tokens (L0–L2b) 748 951 204 YES
P2.4.1 — Capability Gates (derived limits) 952 1101 150 YES
P2.5.1 — Reputation Query MCP Tools 1102 1286 185 YES

Mean entry length: 165 lines. Minimum: 148 (P2.1.1). Floor (80) cleared by every entry. PASS.

3. Per-entry structural conformance (contract §3.2 mandatory subsections)

Each of the 7 sub-task entries was inspected for the seven mandatory subsections:

Subsection P2.1.1 P2.1.2 P2.2.1 P2.2.2 P2.3.1 P2.4.1 P2.5.1
### Files to create YES YES YES YES YES YES YES
### Acceptance criteria YES YES YES YES YES YES YES
### Pre-flight reading YES YES YES YES YES YES YES
### Ready-to-paste agent prompt YES YES YES YES YES YES YES
### Verification checklist (for reviewer agent) YES YES YES YES YES YES YES
### Writeback template YES YES YES YES YES YES YES
### Common gotchas YES YES YES YES YES YES YES

PASS — all 49 subsection cells populated.

4. Header field conformance (contract §3.1)

Each sub-task entry’s header has all 7 required fields:

Header field All 7 entries?
Title ## P2.X.Y — <Title> YES
**Spec source:** task-breakdown.md §P2.X.Y link YES
**Concept reference:** reputation.md section ref YES
**Spec docs:** s04/s05/s09 section refs (where applicable) YES
**Worktree:** feature/p2-x-y-<slug> YES
**Branch command:** git worktree add YES
**Estimated effort:** S/M/L YES
**Depends on:** <upstream tasks> YES
**Unblocks:** <downstream tasks> YES

PASS.

5. Writeback signature conformance (contract §3.4 + packet §7)

All 7 entries’ Ready-to-paste prompt WRITEBACK blocks use the canonical R88.A signature:

thought_record(session_id="r91-lambda-phase-2", thought_type="reflection",
  content="task_id: ...\nbranch: ...\nworktree: ...\ncommit: ...\ntests: ...\nsummary: ...\nblockers: ...")

Grep confirmation:

$ grep -c 'thought_record(session_id="r91-lambda-phase-2", thought_type="reflection"' p2.1-lambda-reputation.md
7

All 7 instances present. No donor-era task_id-as-keyword variants (the form swept out by R88.A) appear anywhere in the file. PASS.

6. File intro conformance (contract §2)

Required intro element Present? Line range
Frontmatter per §2.1 (title/tags/type/status/phase/round/updated) YES 1–9
H1 title # P2 — λ Reputation — Agent Prompts YES 11
Blockquote preamble (canonical/spec/concept/bootstrap/CLAUDE links) YES 13–22
10 design invariants (§2.3) YES 24–34
§Axis goals (1 paragraph) YES 38
§Dependency map (16 upstream rows) YES 40–60
§Ordering rationale (DAG + 4 waves) YES 62–86
§Roadmap budget reference YES 88
§Group summary table (7 rows) YES 90–100
§Out-of-scope (7 deferrals) YES 102–112

PASS — all 10 intro elements present.

7. Spec coverage matrix (contract §4 — the headline acceptance gate)

Every λ surface element from the spec corpus maps to ≥1 sub-task entry’s acceptance criteria checklist:

Surface element (from audit §2.1–§2.8) Sub-task Found in ### Acceptance criteria?
5-domain enum P2.1.1 YES — “5 domain enum: execution \| commissioning \| arbitration \| governance \| social
reputations table fields (score, scar_bps, ban_until, last_activity) P2.1.1 YES — “reputations table schema columns: …”
reputation_history append-only table P2.1.1 YES — “reputation_history table” + “Append-only”
Indexes (node_id, domain) + (domain, score DESC) P2.1.1 YES — “Indexes: idx_reputations_lookup ON (node_id, domain), idx_reputations_leaderboard ON (domain, score DESC)
compute_score with bounded ack_weight P2.1.2 YES — “compute_scoreack_weight … bounded to prevent feedback loops”
Score floor at 0 P2.1.2 + P2.2.1 YES (both) — P2.1.2 “Score floor: 0n”; P2.2.1 “Score floor at 0”
BPS monotonicity property test P2.1.2 YES — “Property test: for any sequence of positive-outcome events, score is monotonically non-decreasing”
Per-epoch decay (inactive only; per-domain reset) P2.2.1 YES — “Decay applies only during inactivity” + “Activity resets timer”
Batch decay 10k+ nodes P2.2.1 YES — “Batch helper apply_decay_batch … efficient for 10,000+ rows”
5 severity bands (minor → fraud) P2.2.2 YES — “Severity band enumMinorFraud
Scar mechanism (permanent cap reduction) P2.2.2 YES — “Scar mechanism: Fraud band adds DAMAGE_FRAUD to scar_bps
Ban mechanism (ban_until_epoch) P2.2.2 YES — “Ban mechanism: Critical/Fraud bands set ban_until_epoch
Double-jeopardy guard P2.2.2 YES — “Double-jeopardy guard: apply_penalty rejects … is_double_penalty(event_id, band, history)
L0/L1/L1.5/L2a/L2b tokens (no L3) P2.3.1 YES — “5 token levels: L0 \| L1 \| L1.5 \| L2a \| L2b
Token non-transferability P2.3.1 YES — “Non-transferable: no helper allows changing node_id
Token append-only event log P2.3.1 YES — “Append-only: no UPDATE or DELETE on experience_tokens
Witness registry (floor 200, weight cap 0.3, sum cap, 7-day independence) P2.3.1 YES — full witness rule block referenced as “L1 → L1.5 promotion … witness rules per s05”
SHA-256 feature hash + diversity gate + invariance gate P2.3.1 YES — “Pattern matching: feature_hash = SHA-256(...)” + “diversity gate” + “invariance check”
max_parallel_tasks(rep) P2.4.1 YES — “max_parallel_tasks(rep: ReputationRow): bigint = min(sqrt_floor(...), 20n)
rate_limit_bonus(rep) P2.4.1 YES — “rate_limit_bonus(rep: ReputationRow, base_rate: bigint)
stake_discount(rep) P2.4.1 YES — “stake_discount(required_stake: bigint, rep: ReputationRow)
can_arbitrate(rep) P2.4.1 YES — “can_arbitrate(rep_arbitration: ReputationRow, rep_execution: ReputationRow)
can_govern(rep) P2.4.1 YES — “can_govern(rep_governance: ReputationRow)
reputation_get P2.5.1 YES — “reputation_get(node_id: string, domain?: Domain)
reputation_history P2.5.1 YES — “reputation_history(node_id: string, domain: Domain, limit?: number, offset?: number)
reputation_leaderboard P2.5.1 YES — “reputation_leaderboard(domain: Domain, limit?: number)
reputation_check_gates P2.5.1 YES — “reputation_check_gates(node_id: string, current_epoch: number)

Coverage: 27/27 surface rows have ≥1 sub-task carrying the element in its acceptance criteria checklist. No spec orphan. PASS.

Each referenced file resolves on disk from docs/guides/implementation/task-prompts/p2.1-lambda-reputation.md:

Target Relative path Resolves?
task-breakdown.md ../task-breakdown.md YES
reputation.md ../../../3-world/social/reputation.md YES
s04-reputation.md ../../../spec/s04-reputation.md YES
s05-experience-tokens.md ../../../spec/s05-experience-tokens.md YES
s09-arbitration.md ../../../spec/s09-arbitration.md YES
agent-bootstrap.md ../../agent-bootstrap.md YES
roadmap.md ../../../5-time/roadmap.md YES
CLAUDE.md ../../../../CLAUDE.md YES
p1.1-kappa-rule-engine.md p1.1-kappa-rule-engine.md YES

ls -la confirmation captured during verification step (9/9 paths resolved on disk; non-zero file sizes). PASS.

9. Out-of-scope assertions (contract §6 + packet §10)

The file intro carries the required out-of-scope block (lines 102–112). All 7 required deferrals are present:

Deferred surface Phase In intro out-of-scope section?
L3 aggregate tokens Phase 6 π YES
Quadratic voting math Phase 6 π YES
θ commit-reveal arbiter voting Phase 3 θ YES
ξ Soul Vector binding Phase 7 ξ YES
Cross-fork L3 recomputation Phase 5 ι YES
Arbitration write-side Phase 3 θ + Phase 6 π YES
Reputation transfer/staking Never YES

PASS.

10. Cross-document consistency (contract §5)

Check Status
All 7 sub-task IDs match task-breakdown.md §Phase 2 (P2.1.1, P2.1.2, P2.2.1, P2.2.2, P2.3.1, P2.4.1, P2.5.1) PASS
task-prompts/index.md updated with Phase 2 row PASS — see commit ee700922; index now carries ## Phase 2 Task Prompts section + new bullet under §After Phase 0
Phase 1 row in index.md status bumped to shipped (R87) PASS — reflects 2026-05-07 reality
reputation.md frontmatter NOT modified PASS — git diff fab4bf57 HEAD docs/3-world/social/reputation.md is empty
No spec docs modified PASS — git diff fab4bf57 HEAD docs/spec/ is empty

11. Gate evidence (contract §7)

Gate Status Evidence
npm run build PASS tsc + postbuild migration copy; 6 migrations copied; zero errors
npm run lint PASS eslint clean (no output)
npm test PASS 47 suites, 2406/2406 tests, 51.4 s

Test count comparison:

  • Base fab4bf57: 2406/2406 across 47 suites (per memory file)
  • After Step 4 commit ee700922: 2406/2406 across 47 suites
  • Delta: 0 (docs-only PR; no test code touched)

PASS.

12. Acceptance criteria final check (contract §8)

Criterion Status
7 sub-task entries present, each ≥ 80 lines, §3.2 structure PASS (§2, §3)
File intro per §2.2 subsections PASS (§6)
10 design invariants per §2.3 PASS (§6 line 24–34)
Dependency map cites every entry in §2.4 PASS (§6 line 40–60; 16 rows)
Every spec surface row in §4 maps to ≥ 1 sub-task PASS (§7; 27/27)
Frontmatter matches §2.1 exactly PASS (§6 line 1–9)
Relative links per §3.5 all resolve PASS (§8; 9/9)
Out-of-scope per §6 in intro PASS (§9; 7/7)
task-prompts/index.md updated with Phase 2 row PASS (§10)
No changes to reputation.md or spec docs PASS (§10)
npm run build && npm run lint && npm test green PASS (§11)

All 11 acceptance criteria satisfied. R89.B λ Phase 2 Staging is COMPLETE.

13. Commit chain

Step Commit Subject
1 — Audit 90659099 audit(r89-b-lambda-phase-2-staging): inventory spec surface
2 — Contract bed68027 contract(r89-b-lambda-phase-2-staging): behavioral contract for prompt file
3 — Packet 6615ea09 packet(r89-b-lambda-phase-2-staging): execution plan + ordering rationale
4 — Implement ee700922 feat(r89-b-lambda-phase-2-staging): stage P2.1.1-P2.5.1 prompt file for lambda Reputation
5 — Verify (this commit) verify(r89-b-lambda-phase-2-staging): test evidence

14. Residual risks / blockers

  • None identified. Phase 2 dispatch can begin at R91 by PM copying the Ready-to-paste prompt blocks verbatim from the file into the host Task tool.
  • The session_id placeholder r91-lambda-phase-2 in every WRITEBACK block is expected — PM updates at dispatch time to the actual round identifier (e.g. r91-lambda or r91.B-lambda).
  • MIN_EPISODES = 5n is named in p2.3.1 Common gotchas as needing to be added to bps-constants.ts; this is captured in the prompt itself and is not a staging-level blocker.

15. Verification conclusion

The prompt file docs/guides/implementation/task-prompts/p2.1-lambda-reputation.md satisfies every contract clause from Step 2 and every packet clause from Step 3. The seven sub-task entries cover the full λ Reputation Phase 2 surface as catalogued in the spec corpus (s04 + s05 + s09 + reputation.md), with zero spec orphan and zero out-of-scope surface bleed. All gates pass; all links resolve; all writeback signatures are R88.A-compliant.

Phase 2 λ is dispatch-ready.


R89.B λ Phase 2 Staging Step 5 (Verification) — 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.