memory + backlog: parallelism scaling ladder + PM-split + fitness-function-first + amortized-keystone (Aaron 2026-05-01)

docs/BACKLOG.md

@@ -34,6 +34,8 @@ are closed (status: closed in frontmatter)._
 - [ ] **[B-0125](backlog/P1/B-0125-skip-fsharp-analyze-on-docs-only-prs-2026-05-01.md)** Skip F#/Analyze (csharp) on docs-only PRs without tripping `code_quality severity:all`
 - [ ] **[B-0126](backlog/P1/B-0126-port-meta-learning-4-layer-pattern-from-stcrm-aaron-2026-05-01.md)** Port the 4-layer meta-learning pattern from a sibling repo to Zeta
 - [ ] **[B-0140](backlog/P1/B-0140-bash-to-ts-migration-completion-debt-prevention-aaron-2026-05-01.md)** Bash → TS migration completion — debt-prevention prerequisite to B-0132 (CRDT-composition)
+- [ ] **[B-0144](backlog/P1/B-0144-doc-code-two-lane-parallel-split-aaron-2026-05-01.md)** Doc/code two-lane parallel split — rung-2 unlock for factory parallelism
+- [ ] **[B-0145](backlog/P1/B-0145-product-manager-role-research-to-predict-features-before-friction-aaron-2026-05-01.md)** Product Manager (PM-2) role — research-to-predict-features-before-friction
 
 ## P2 — research-grade
 
@@ -104,6 +106,7 @@ are closed (status: closed in frontmatter)._
 - [ ] **[B-0132](backlog/P2/B-0132-crdt-composition-for-bft-propagation-aaron-2026-05-01.md)** CRDT-composition for BFT propagation — substrate events as composed CRDTs
 - [ ] **[B-0133](backlog/P2/B-0133-sequent-calculus-for-claim-retraction-attribution-aaron-2026-05-01.md)** Sequent calculus / labeled deductive systems for claim/retraction/attribution
 - [ ] **[B-0134](backlog/P2/B-0134-type-theoretic-orthogonality-discipline-encoding-aaron-2026-05-01.md)** Type-theoretic encoding of orthogonality discipline (extension vs creation as decidable judgment)
+- [ ] **[B-0146](backlog/P2/B-0146-formal-architecture-ladder-explicit-layer-declaration-aaron-2026-05-01.md)** Formal architecture ladder — explicit-layer-declaration discipline for B-rows
 - [ ] **[B-0147](backlog/P2/B-0147-timeseries-db-native-in-zsets-multi-dsl-integration-research-aaron-2026-05-01.md)** TimeSeries DB native-in-Zsets multi-DSL integration research (metrics-are-our-eyes)
 - [ ] **[B-0148](backlog/P2/B-0148-mdx-as-meta-dsl-framing-fsharp-mdx-dsl-implementation-aaron-2026-05-01.md)** MDX as meta-DSL framing for multi-DSL Zset substrate + F# MDX DSL implementation
 - [ ] **[B-0149](backlog/P2/B-0149-prometheus-mcp-integration-promtool-factory-agents-direct-query-aaron-2026-05-01.md)** Prometheus MCP integration + promtool — factory agents direct-query observability

docs/backlog/P1/B-0144-doc-code-two-lane-parallel-split-aaron-2026-05-01.md

@@ -0,0 +1,156 @@
+---
+id: B-0144
+priority: P1
+status: open
+title: Doc/code two-lane parallel split — rung-2 unlock for factory parallelism
+created: 2026-05-01
+last_updated: 2026-05-01
+---
+
+# B-0144 — Doc/code two-lane parallel split
+
+## What
+
+Operationalize a two-lane parallel-subagent dispatch pattern
+where one lane mutates `docs/**` (with `memory/**`,
+`openspec/**`) and the other lane mutates code (`src/Core/**`,
+`src/Core.CSharp/**`, `src/Bayesian/**`, `tools/**` excluding
+`tools/lint/`). Both lanes
+run concurrently in **isolated worktrees** per the established
+worktree-isolation discipline. Coordinator (Otto) merges via
+PR-with-merge-queue cadence.
+
+## Why now
+
+Aaron 2026-05-01 explicitly named this as the next-rung-up
+unlock for factory parallelism:
+
+> *"if we get that doc/code split two lanes that will open you
+> up and then you can split further by file isoletion for more
+> parallel lanes and build you way there and save lessions to
+> reduce fiction for more lanes"*
+
+Per the parallelism scaling ladder (rung 2 of 5) captured in
+`memory/feedback_parallelism_scaling_ladder_kenji_unlocked_loop_agent_doc_code_two_lane_file_isolation_peer_mode_claims_automated_best_practice_at_scale_aaron_2026_05_01.md`,
+this is the immediate next throughput multiplier with
+structurally-near-zero collision risk because docs and code
+have disjoint file trees, disjoint review-disciplines, and
+disjoint mechanized-best-practice toolchains.
+
+## Acceptance criteria
+
+1. **Worktree isolation pattern documented** in
+   `tools/lanes/README.md` covering:
+   - How to allocate the doc-lane worktree
+     (`tools/lanes/doc-lane.sh allocate <branch>`)
+   - How to allocate the code-lane worktree
+     (`tools/lanes/code-lane.sh allocate <branch>`)
+   - File allowlist per lane (doc-lane writes to `docs/**`,
+     `memory/**`, `openspec/**`, `*.md` at root; code-lane
+     writes to `src/Core/**`, `src/Core.CSharp/**`,
+     `src/Bayesian/**`, `tools/**` excluding `tools/lint/`,
+     `*.fs`, `*.fsproj`)
+   - File denylist per lane (doc-lane never writes code-tree
+     files; code-lane never writes `docs/**` or `memory/**`)
+
+2. **Subagent prompt templates** at
+   `tools/lanes/prompts/doc-lane-template.md` and
+   `tools/lanes/prompts/code-lane-template.md` that codify the
+   lane discipline so subagents inherit the constraints
+   without coordinator re-explaining each tick.
+
+3. **Coordinator coordination protocol** documented:
+   - Coordinator allocates BOTH worktrees BEFORE dispatching
+     EITHER subagent (Amara 2026-04-29 rule:
+     *"coordinator must allocate worktrees before
+     allocating agents"*)
+   - Coordinator dispatches both subagents in the SAME tool
+     call (parallel block)
+   - Coordinator waits for BOTH lanes' branch-pushes before
+     opening PRs
+   - Coordinator opens both PRs together (visibility:
+     reviewer can see the lane-shape)
+   - Coordinator merges in dependency order (or queues both
+     in merge queue)
+
+4. **First demonstrated dry-run.** A real tick where:
+   - Doc-lane subagent fixes a thread on a `docs/**` PR
+   - Code-lane subagent fixes a thread on a code PR
+   - Both run concurrently
+   - Both PRs land cleanly without cross-lane interference
+   - Tick-history row records which lanes ran
+
+5. **Lessons-mechanization step.** Any friction surfaced in
+   the dry-run produces a memory-file or BP-NN candidate
+   that mechanizes the decision per the
+   automated-best-practice-decision-making-at-scale
+   discipline.
+
+## Out of scope (rung 3+ — defer)
+
+- **N>2 file-isolation lanes** — covered by future B-row
+  after rung 2 demonstrates clean operation. Rung 3 is the
+  generalization, not a separate design.
+- **Cross-harness parallel-mode** — covered by the
+  agent-orchestra cluster (#324–#339). Rung 5; defer.
+- **Automatic lane-classification** — *"is this a doc fix
+  or code fix?"* — initially manual coordinator-call;
+  mechanization candidate for later (would belong in
+  `tools/lanes/classify.sh`).
+
+## Risks
+
+- **Stash collisions** if worktree-isolation slips — mitigated
+  by mechanical worktree-allocation rule (4-criterion above).
+- **Formatter bleed-through** (e.g., `prettier --write` running
+  repo-wide from one lane) — mitigated by lane-allowlist
+  enforcement and `--check` mode preferred for cross-cutting
+  tools.
+- **Reviewer load doubling** — two PRs open at once may feel
+  like more review surface; mitigated by mechanized
+  best-practice toolchain handling 80%+ of review surface
+  automatically (per
+  `memory/feedback_parallelism_scaling_ladder_kenji_unlocked_loop_agent_doc_code_two_lane_file_isolation_peer_mode_claims_automated_best_practice_at_scale_aaron_2026_05_01.md`
+  rung-4 discipline).
+- **Coordinator complexity** — managing two lanes is more
+  bookkeeping than one; mitigated by codifying the
+  coordination protocol (acceptance criterion #3) so it
+  becomes mechanical.
+
+## Composes with
+
+- `memory/feedback_parallelism_scaling_ladder_kenji_unlocked_loop_agent_doc_code_two_lane_file_isolation_peer_mode_claims_automated_best_practice_at_scale_aaron_2026_05_01.md`
+  — the architectural framing this row operationalizes (rung 2)
+- `memory/feedback_parallel_agents_need_isolated_worktrees_coordinator_owns_main_aaron_amara_2026_04_29.md`
+  — the worktree-isolation discipline this row instantiates
+- `memory/project_loop_agent_named_otto_role_project_manager_2026_04_23.md`
+  — Otto-as-PM role definition (the coordinator)
+- `memory/feedback_zeta_agent_orchestra_capability_role_claim_isolation_aaron_amara_2026_04_29.md`
+  — the agent-orchestra design (rung 5; this row's
+  long-term endpoint)
+- B-0130 (verify-before-state-claim mechanized auditor),
+  plus B-0141 (pre/post pattern) and B-0142 (Code Contracts
+  revival) when they land — mechanization primitives that
+  compound the rung-4
+  lessons-to-reduce-friction discipline
+
+## Effort
+
+**M (medium, 1–3 days)** for the documented protocol +
+allocator scripts + subagent prompt templates + first dry-run.
+Lessons-mechanization is open-ended (continues across all
+future ticks operating in two-lane mode).
+
+## Why P1 (not P0 / not P2)
+
+- **Not P0** because the factory functions today without it
+  (rung-1 serial-subagent dispatch works); it is a throughput
+  unlock, not a correctness fix.
+- **Not P2** because the guardrail (per-PR quality) explicitly
+  requires the mechanization-of-best-practice-decisions
+  infrastructure to scale — and this row is the proving
+  ground for that infrastructure. Deferring it defers the
+  evidence we need for rungs 3–5.
+- **P1** because every future tick that runs serial when it
+  could have run parallel is forgone throughput; the cost
+  compounds.

docs/backlog/P1/B-0145-product-manager-role-research-to-predict-features-before-friction-aaron-2026-05-01.md

@@ -0,0 +1,222 @@
+---
+id: B-0145
+priority: P1
+status: open
+title: Product Manager (PM-2) role — research-to-predict-features-before-friction
+created: 2026-05-01
+last_updated: 2026-05-01
+---
+
+# B-0145 — Product Manager (PM-2) role — research-to-predict-features-before-friction
+
+## What
+
+Define and operationalize a **Product Manager (PM-2)** role
+that runs **proactive research-driven cadence** to predict
+feature gaps and surface them as backlog rows BEFORE the
+loop encounters them as friction. Distinct from the
+**Project Manager (PM-1, Otto)** role which is
+reactive/loop-driven.
+
+## Why now
+
+Aaron 2026-05-01:
+
+> *"this seem like it would make my PM a real company say hey
+> you know what we are missing a feature and then there is the
+> other kind of (first kind being Project Manager) the 2nd
+> Product Manager who should have done research to predict you
+> we had the missing feature before running into the issue with
+> the product."*
+
+The parallelism scaling ladder (per
+`memory/feedback_parallelism_scaling_ladder_kenji_unlocked_loop_agent_doc_code_two_lane_file_isolation_peer_mode_claims_automated_best_practice_at_scale_aaron_2026_05_01.md`)
+multiplies *throughput*, but does not change *direction*. The
+direction-axis requires a role that does **forward research**
+— PM-2 — distinct from the reactive-cadence role (Otto / PM-1).
+Without PM-2, every feature-gap is discovered by stumbling
+into it; with PM-2, gaps are queued before they block work.
+
+Aaron's framing locates the gap precisely: *"who should have
+done research to predict you we had the missing feature before
+running into the issue with the product."* The counterfactual
+standard (*should have*) names PM-2 by its absence.
+
+## Scope (what PM-2 does)
+
+1. **Forward research cadence** — weekly or per-round (longer-
+   than-tick) review of:
+   - `docs/TECH-RADAR.md` (Trial / Adopt / Hold rows)
+   - Recent Claude.ai / Amara / peer-AI ferries (`docs/research/`)
+   - Upstream-doc WebSearch per Otto-364 (search-first authority)
+   - Demo target requirements (`task #244` factory-demo)
+   - Consumer-facing API audits (`src/Core/**` public surface)
+   - GLOSSARY churn (terms moving in vocabulary signal
+     surface evolution)
+   - Recent CONFLICT-RESOLUTION conferences (where a
+     conference revealed a gap)
+   - External attack-surface scouting (Mateo's outputs;
+     PM-2 picks up what Mateo flags as not-pure-security)
+
+2. **Feature-gap-prediction outputs** — produces backlog
+   rows (B-NNNN format) for predicted gaps:
+   - One row per discrete missing feature
+   - Includes: signal-source (what evidence pointed to
+     the gap), expected-encounter-window (when will the
+     loop hit this), priority (P0/P1/P2/P3), proposed
+     scope (size estimate)
+   - Uses the standard `docs/backlog/<priority>/B-NNNN-*.md`
+     filename pattern
+
+3. **TECH-RADAR row updates** — promotes / demotes rows
+   based on forward research:
+   - Trial → Adopt when evidence accumulates
+   - Adopt → Hold when an emerging better option appears
+   - New rows when a watched-trajectory matures into
+     evaluation-ready
+
+4. **Forward-radar periodic memos** — short (1-2 page)
+   forward-look documents at round boundaries summarizing
+   *what is coming* — not the same as ROUND-HISTORY
+   (backward-look). Lives at `docs/forward-radar/YYYY-MM-DD-*.md`.
+
+## Acceptance criteria
+
+1. **Role definition** at `docs/EXPERT-REGISTRY.md` (extend
+   existing roster) defining PM-2 distinctly from PM-1
+   (Otto). Persona-name to be picked via the standard
+   naming-expert review process; until then, role-ref
+   "Product Manager" / PM-2.
+
+2. **Cadence schedule** — initial weekly cadence; reviewed
+   after first 4 cycles. PM-2 fires on Sundays UTC (not
+   tick-driven; longer-than-tick).
+
+3. **Output template** at `docs/forward-radar/TEMPLATE.md`
+   covering: signal-sources reviewed, predicted gaps
+   (with B-row pointers), TECH-RADAR row changes, calibration
+   note (% of last-period friction-encounters that were
+   already in backlog as predicted gaps).
+
+4. **First forward-radar memo** lands within 2 weeks of
+   role activation, covering the first round's research.
+
+5. **Calibration metric tracked** — quarterly review of
+   *what % of friction-encounters in the loop were
+   ALREADY in the backlog as PM-2-predicted gaps*. Target
+   trajectory: starts low (PM-2 has no warm-up), rises
+   over time. Metric persistence in
+   `docs/forward-radar/calibration.md`.
+
+## Quality test (the load-bearing one)
+
+PM-2's effectiveness is **NOT** measured by:
+
+- Volume of memos produced (memo-count is overhead)
+- Volume of B-rows filed (gap-prediction-count is
+  bureaucracy)
+
+PM-2's effectiveness IS measured by:
+
+- **Lead-time%** — of friction-encounters in the loop, what
+  fraction had been predicted in the backlog before they
+  surfaced? Target trajectory: 0% (cold-start) → 20%
+  (calibrated) → 50%+ (mature).
+- **Action-rate%** — of PM-2's predicted-gap B-rows, what
+  fraction has PM-1 (Otto) picked up within 4 rounds?
+  Below 20% = PM-2 is producing noise; above 80% = PM-2
+  is feeding the queue effectively.
+
+Both must be tracked. PM-2 with high lead-time but low
+action-rate is producing *predictions no one trusts*; PM-2
+with high action-rate but low lead-time is producing
+*backlog churn that adds nothing the loop wouldn't have
+caught*.
+
+## Anti-patterns this role guards against
+
+1. **More bureaucracy.** Research-without-action is overhead.
+   PM-2 outputs land as actionable backlog rows; if PM-2 is
+   producing memos no one acts on, the role is failing —
+   stop, retire, fix.
+
+2. **Authority creep.** PM-2 *predicts gaps*; PM-2 does NOT
+   *decide what gets built*. The Architect (Kenji) and the
+   maintainer (Aaron) decide priorities. PM-2 surfaces;
+   they prioritize.
+
+3. **Persona-sprawl.** Per
+   `memory/project_loop_agent_named_otto_role_project_manager_2026_04_23.md`
+   — Otto fills the hat-less default; future roles should
+   not multiply persona-names without a discrete
+   role-shape. PM-2 has a discrete role-shape (proactive
+   research-driven, distinct from reactive loop-driven),
+   which justifies the addition.
+
+4. **Confusion with existing PM-2-flavored work.** Mateo
+   (Security-Researcher) does proactive security scouting;
+   Aarav (Skill-Expert) does proactive skill scouting;
+   Iris (UX) and Bodhi (DX) do proactive UX/DX research
+   in narrow slices. PM-2 does **not** absorb their
+   scope. PM-2 owns the *integrated forward-view across
+   feature/product layer*, NOT security, skills, UX, or
+   DX research that already has owners.
+
+## Out of scope (defer)
+
+- **Persona-name pick** — defer to naming-expert review
+  + maintainer nudge per the standard cadence. Until
+  then, role-ref only.
+- **PM-2 automation/mechanization** — initial cycles are
+  human-run (or Otto-run when Otto wears the PM-2 hat).
+  Mechanization candidates emerge after 3+ cycles
+  surface repeatable patterns.
+- **Research-budget allocation** — PM-2 is free-tier work
+  initially; paid-tier expansion (e.g., scheduled remote
+  routines for forward-radar generation) is a separate
+  decision per
+  `memory/feedback_free_work_amara_and_agent_schedule_paid_work_escalate_to_aaron_2026_04_23.md`.
+
+## Composes with
+
+- `memory/feedback_parallelism_scaling_ladder_kenji_unlocked_loop_agent_doc_code_two_lane_file_isolation_peer_mode_claims_automated_best_practice_at_scale_aaron_2026_05_01.md`
+  — the architectural framing that names this role as
+  the direction-axis complement to the throughput-axis
+  scaling ladder
+- `memory/project_loop_agent_named_otto_role_project_manager_2026_04_23.md`
+  — Otto = PM-1 (reactive); this row defines PM-2 (proactive)
+- `docs/EXPERT-REGISTRY.md` — extension target for the
+  role definition
+- `docs/TECH-RADAR.md` — primary input + output surface
+  for PM-2's forward-research cadence
+- `docs/CONFLICT-RESOLUTION.md` — when PM-2's predictions
+  conflict with PM-1's queue, the conference protocol
+  is the rail
+- B-0144 — sibling rung-2 work (scaling ladder); this row
+  is on the orthogonal direction-axis
+- task #244 (factory-demo target) — PM-2's first concrete
+  forward-research target should be: *"what features does
+  the factory-demo need that we don't have yet?"*
+
+## Effort
+
+**M (medium, 1–3 days)** for role-definition, cadence-schedule,
+output-template, and first forward-radar memo. Calibration-
+metric tracking is open-ended (continues across all future
+PM-2 cycles).
+
+## Why P1 (not P0 / not P2)
+
+- **Not P0** because the factory functions today without it
+  (PM-1 reactive cadence catches gaps when they surface);
+  it is a lead-time / direction unlock, not a correctness fix.
+- **Not P2** because the parallelism scaling ladder
+  (B-0144 et seq.) increases the COST of feature-gap
+  surprises — at higher throughput, every stumble-into-a-
+  missing-feature blocks more parallel lanes. PM-2 lead-time
+  is the multiplier that lets the throughput-axis pay off.
+- **P1** because shipping the factory-demo (task #244) is
+  the next major-target, and the PM-2 forward-research
+  *"what does the demo need that we don't have"* is exactly
+  the kind of question PM-2 should be answering before the
+  demo hits walls.