Founder locks (2026-05-12 20:39 ET iMessage)

The 2 load-bearing choices are locked. The 3 smaller questions remain open (no rush).

Bootstrap shape (section 3.7) → Recommendation D approved, with a sharpening. Founder: "If we do not have evaluation criteria the first few times let me be the critic. Use that feedback to generate our canonical critic." The bootstrap is not just founder-as-critic-for-the-meta-build — it extends into the early production runs. Founder feedback during the bootstrap phase IS the labeling phase that codifies the canonical critic. Transition to autonomous critic happens silently when per-axis label volume crosses some threshold (TBD as part of the schema work).
Canonical-set shape (section 3.5) → Recommendation D approved (hybrid). Founder: "Use the canonical shape where we have it." Structural YAML where deterministic axes exist; reference-artifact folder where exemplars exist; founder critic fills in where neither is locked yet.
Sharpening (founder framing): "Isn't this essentially the RLHF loop?" Yes. Structurally identical topology — founder critique acts as preference labels, the pipeline-critic agent acts as the reward model, the spec / test / code seats act as the policy, loop iterations are the RL updates. Different MECHANISM from textbook RLHF (which trains a parametric reward model via gradient descent on preference pairs) — ours codifies feedback into critic prompts + reference exemplars + structural YAML axes. Closer to Constitutional AI / iterative-critique-then-revise. Concept article filed at ~/rdco-vault/06-reference/concepts/2026-05-12-rdco-pipeline-rlhf-shaped.md.

The 3 smaller questions (section 4 items 3-5) remain open — first domain pick, decision-page click-back as v1 or v1.1, axis-fragment registry path.

Multi-agent skill build-out pipeline — architecture (draft for founder review)

1. Purpose

This doc enumerates the load-bearing design choices for the 4-seat skill build-out pipeline (spec author → test author → code author → critic) so the founder can lock the architecture before any seats, configs, or smoke tests are built. For each choice it lists 2-4 options with terse pros/cons and a recommended option. Output of approval: a YAML schema for per-domain configs, four SKILL.md drafts for the utility seats, and a smoke test against one toy domain. Nothing in this doc commits code — it only commits shape.

2. Reading-derived context

The four sources collectively say the same load-bearing thing from four vantage points. Lloyd (Warp) is the lived-experience proof: ship the canonical reference set first, run a sharded fleet of CV-comparison critics in parallel, hill-climb 10-15 runs until visual diffs go to zero. Tan (YC) names the temporal mechanism: every agent turn must produce tests + docs + evals so the next turn cannot regress — the "agent complexity ratchet." Jaynit names the pattern-formation mechanism: volume + tight feedback + articulation; warns of false-pattern overfitting when feedback is loose. The decision page captures the founder's structural worry: when the same seat writes spec + tests + code, tests rubber-stamp the code instead of the ground truth — separating seats is the structural fix. Cross-cutting tension surfaced in the reading: Lloyd had a reference implementation (mermaid.js) to generate the canonical set; most RDCO skill domains do not, so the canonical-set construction step is heavier for us than Lloyd's case study admits.

3. Load-bearing design choices

3.1 Seat invocation pattern

Question: How does a workflow command (/build-<domain>) invoke the 4 seats in sequence?

Options:

A. Direct Agent-tool subagent dispatch, one per seat, with skill param set to the seat skill. Pros: cleanest context isolation, parent agent stays in orchestrator role, matches /process-newsletter batch shape. Cons: parent must explicitly thread artifacts between calls; 4 round-trips of agent spin-up cost.
B. Named CLI commands chained in a shell pipeline (pipeline-spec | pipeline-test | pipeline-code | pipeline-critic). Pros: trivially scriptable, easy to dry-run a single seat. Cons: each command needs its own LLM session bootstrap; weak handoff format guarantees; harder to embed in Skill ecosystem.
C. Single orchestrator skill that imports the seats as in-process callables. Pros: zero handoff overhead, one context budget. Cons: collapses the very context-isolation Tan/Lloyd require — seat 2 sees seat 1's reasoning, defeating the rubber-stamp prevention.
D. Skill tool chaining where the workflow skill internally calls Skill on each seat skill in order. Pros: leverages built-in skill system; uniform invocation. Cons: Skill tool calls run in parent context — same context-leak problem as C.

Recommendation: A. It's the only option that preserves the structural property the founder asked for (no seat sees upstream reasoning, only upstream artifacts). The 4 round-trips cost is bounded and worth it.

3.2 Seat-to-seat handoff format

Question: How does spec-author hand its artifact to test-author? Test-author to code-author?

Options:

A. Filesystem — vault paths written by each seat, next seat reads by path. Pros: artifacts are durable, inspectable, diffable, and live next to the eventual SOP per Lloyd's "prompts live with the skill" pattern. Cons: requires per-run scratch directory convention; cleanup discipline.
B. Structured stdout/stdin via subagent return value (JSON blob with artifact embedded). Pros: no filesystem state; clean ephemeral runs. Cons: artifacts disappear after the run, losing the audit trail Tan's ratchet depends on; binary/large artifacts awkward.
C. In-memory passing via parent agent's context (parent reads each seat's return, includes it in next seat's prompt). Pros: simplest plumbing. Cons: parent context bloats fast; the artifacts effectively re-enter parent context defeating the routing-long-artifacts-through-subagents rule (CLAUDE.md hard rule 4).

Recommendation: A. Per-run dir at ~/rdco-vault/01-projects/skill-pipelines/runs/<domain>-<timestamp>/{spec.md, tests.md, code/, critic/}. Durable, auditable, satisfies the ratchet's "docs + evals accumulate" requirement.

3.3 Critic shard parallelization

Question: How do the N critic axes (e.g. frontmatter completeness, RDCO mapping strength, sponsor disclosure, cross-link richness) run?

Options:

A. Parent agent dispatches N subagents in one parallel Agent-tool batch, one per axis. Pros: matches Lloyd's 20-shard fleet pattern exactly; each axis stays in isolation; wall-clock fast. Cons: parent must aggregate N return values.
B. Single critic agent that iterates axes serially. Pros: cheaper, simpler. Cons: serial axes leak context to each other (axis 3 sees axis 1+2's diagnoses); slower; loses the parallel-isolation property that prevents axis-coupling false patterns.
C. Each critic axis as its own Skill (pipeline-critic-frontmatter, pipeline-critic-rdco-mapping, ...). Pros: maximally namespaced; each axis can evolve independently. Cons: skill-file sprawl; per-domain critic axes can't be enumerated until the domain config exists; awkward for a 3-axis domain to install 3 skills vs a 10-axis domain installing 10.

Recommendation: A. Critic axes are declared in the per-domain YAML; the single pipeline-critic seat fans them out as parallel subagent dispatches with axis=<name> as the seat parameter. Preserves Lloyd's parallel-isolation property without proliferating skill files.

3.4 Convergence detection

Question: How does the loop know to stop?

Options:

A. Critic returns explicit PASS/FAIL per axis; parent ANDs them; loop until all PASS or N iterations exceeded. Pros: matches Lloyd's "until visual diffs are zero" shape; matches existing /video-critic and /design-critic verdict shape. Cons: binary PASS hides "almost-pass" cases.
B. Critic returns a numerical delta per axis; parent thresholds against a configured value. Pros: continuous signal; can detect monotonic improvement vs stall. Cons: thresholds are arbitrary per-axis and per-domain; harder to calibrate; can hill-climb forever near threshold.
C. Manual founder gate after each iteration. Pros: maximum safety. Cons: defeats the autonomous loop; founder becomes the bottleneck; contradicts the auto-mode signal-to-noise memory.
D. Hybrid: PASS/FAIL primary, with a confidence field that surfaces "PASS but weak" for the founder's eye without blocking. Pros: keeps the loop autonomous; gives founder visibility into shaky passes without gating. Cons: more critic-return surface area.

Recommendation: D. Aligns with /video-critic's existing PASS/ITERATE/SCRAP shape; the confidence field is the audit hook Tan's ratchet wants without making the loop manual.

3.5 Canonical-set representation

Question: How is the ground truth structured for the critic to compare against?

Options:

A. Folder of reference artifacts that critic fuzzy/semantic-compares against. Pros: matches Lloyd's directly; closest to how RDCO already operates (past Sanity Check pieces, past briefs, past MAC matrices serve as templates today). Cons: fuzzy compare is judgment-laden; risk of overfitting to one reference style.
B. JSON/YAML file enumerating axis-by-axis expected properties (e.g. frontmatter.required_keys: [...], rdco_mapping.minimum_seat_links: 2). Pros: machine-checkable; deterministic; cheap. Cons: only captures structural properties, misses style/voice/quality; flatter than ground truth actually is.
C. Single "golden" artifact per axis (one canonical example the critic compares against). Pros: simple. Cons: single point of overfitting; one artifact's idiosyncrasies become "the rule."
D. Hybrid — YAML declares structural axes (option B) PLUS a folder of 3-5 reference artifacts (option A) that the critic uses for style/voice axes. Pros: deterministic where possible, fuzzy where unavoidable; resists overfitting better than C. Cons: two artifact types to maintain.

Recommendation: D. Maps to the actual shape of RDCO domains — frontmatter/cross-link checks are mechanical (B-style), voice/RDCO-mapping/judgment checks need reference exemplars (A-style). Mitigates the Lloyd-gap surfaced in section 2 (most RDCO domains don't have a programmatic oracle).

3.6 Failure mode handling

Question: What happens when the critic can't converge after N iterations?

Options:

A. Surface to founder with diagnostic + axis-by-axis diffs. Pros: founder sees exactly where the loop stalled; reuses the channel reply pattern. Cons: pulls founder attention.
B. Archive the run + open a decision page (HQ click-back wire). Pros: founder can defer judgment; decision page is the existing surface for this; aligns with hq-as-decision-surface concept. Cons: indirection delays the loop; not great for time-sensitive builds.
C. Fall back to founder-gated single-shot mode (IC-mode). Pros: ensures something ships; useful escape hatch. Cons: throws away the pipeline's structural guarantees; risks the rubber-stamp pattern returning by the back door.
D. Tiered: at N/2 iterations log a warning to the run dir; at N stop, archive, and open a decision page (B) — never silently fall back. Pros: founder visibility scaled to severity; ratchet integrity preserved; reuses existing decision-page surface. Cons: requires implementing N/2 warning hook.

Recommendation: D. Preserves the ratchet's forward-only motion (no silent fallback), uses the decision-page surface the founder already trusts, and gives an early-warning signal before full failure.

3.7 Bootstrap problem

Question: The pipeline-spec-author seat itself needs to be built. How do we resolve the "you can't use the pipeline to build itself" recursion?

Options:

A. Hand-bootstrap the 4 seats IC-mode (single-shot subagents, founder reviews each SKILL.md), accept looser quality on the bootstrap. Pros: pragmatic; gets us to a working pipeline fast; founder review compensates for missing critic. Cons: bootstrap quality is exactly the rubber-stamp risk the pipeline exists to prevent.
B. Build a minimal toy pipeline first (e.g. a /build-haiku-generator domain) that's only used to validate the schema, then use that toy pipeline to build the real seats. Pros: dogfoods the pipeline; smoke-tests the schema before any real domain depends on it. Cons: still needs hand-bootstrap of the toy; nested recursion concern.
C. Defer the bootstrap question to the founder. Pros: founder owns the meta-decision. Cons: passes the buck on the most interesting structural question.
D. Hybrid — hand-bootstrap (A) the 4 seats with a TIGHTENED founder review step (treat the founder as the first critic for the bootstrap only), then use the bootstrapped pipeline to build the first real domain (/build-website-discovery) as the validation run. Pros: founder is the critic exactly when the structural critic doesn't exist yet; first real domain build IS the smoke test; quality risk bounded by founder gate. Cons: founder time on the bootstrap review.

Recommendation: D. The bootstrap is the only build where founder-as-critic doesn't violate the auto-mode signal-to-noise memory — it's a one-time meta-build, not a recurring workflow. After bootstrap, the pipeline runs autonomously.

3.8 Inter-domain config inheritance

Question: When MAC config and SC-article config share critic axes (e.g. both want a frontmatter-completeness check), do they share via inheritance or duplicate inline?

Options:

A. Per-domain YAML fully self-contained, no inheritance. Pros: simplest to reason about; one file per domain; no spooky-action-at-a-distance. Cons: duplication; updating a shared axis means N file edits; drift risk between domains over time.
B. Shared base config that domain configs extend via extends: base.yaml. Pros: DRY; one place to update shared axes. Cons: harder to read a single config in isolation; inheritance chains hide actual behavior; base file becomes a contested artifact.
C. Library of reusable critic-axis fragments referenced by name (axes: [shared/frontmatter-completeness, shared/cross-link-richness, custom/mac-scope-basis-coverage]). Pros: composable; reusability without inheritance complexity; named fragments are inspectable in isolation; matches how hyperframes registry blocks work. Cons: requires a fragment registry path convention.

Recommendation: C. Fragments live at ~/rdco-vault/01-projects/skill-pipelines/axes/<name>.yaml. Domain configs list the axes they want. Matches the founder's existing mental model from the hyperframes registry pattern (blocks composed by name). Single source of truth per axis without the inheritance footgun.

3.9 Triggering surfaces

Question: Are the 3 triggering modes sufficient, or is there a 4th?

The 3 confirmed modes:

Founder-direct CLI invocation — /build-<domain> <args> typed in a session.
Notion-board-task dispatch via /check-board — the autonomous loop picks up a queued build ticket and fires the workflow.
Internal subagent dispatch from a parent skill — e.g. /process-newsletter discovers a newsletter type it doesn't have a skill for and dispatches /build-<domain> to scaffold one.

A 4th surface surfaced in the reading:

Decision-page click-back — after a decision page lands an APPROVE verdict (the wire pattern the founder used for THIS very ticket), the iMessage return-channel could include a structured BUILD:<domain> token that triggers the workflow directly without a Notion-board hop. Per the imessage-as-generative-ui memory, sms:?body= already routes back to the session.

Recommendation: confirm 3 modes for v1, add the 4th (decision-page click-back) as a v1.1 enhancement. The first three cover the founder's question. The decision-page click-back is real but pulls work to a surface that isn't fully load-bearing yet; defer until at least one domain ships through the first three.

3.10 (Unprompted) Namespacing — utility seats vs domain workflows vs configs

Question: Where do the four files live and how are they named so the founder can find them?

The founder explicitly asked about namespacing. Proposed layout (this is the namespacing answer in concrete form):

~/.claude/skills/pipeline-spec-author/SKILL.md      # utility seat (domain-agnostic)
~/.claude/skills/pipeline-test-author/SKILL.md      # utility seat
~/.claude/skills/pipeline-code-author/SKILL.md      # utility seat
~/.claude/skills/pipeline-critic/SKILL.md           # utility seat

~/.claude/skills/build-website-discovery/SKILL.md   # domain workflow (orchestrator)
~/.claude/skills/build-mac-matrix/SKILL.md          # domain workflow (future)
~/.claude/skills/build-sc-article/SKILL.md          # domain workflow (future)

~/rdco-vault/01-projects/skill-pipelines/
  configs/website-discovery.yaml                    # per-domain config
  configs/mac-matrix.yaml
  configs/sc-article.yaml
  axes/frontmatter-completeness.yaml                # reusable critic-axis fragment
  axes/rdco-mapping-strength.yaml
  axes/sponsor-disclosure.yaml
  references/<domain>/<artifact>.md                 # canonical reference set per domain
  runs/<domain>-<timestamp>/                        # per-run scratch

Recommendation: use this layout exactly as drawn. The pipeline-* prefix segregates utility seats from domain workflows (build-*) at a glance. Configs and axes in the vault (not in ~/.claude/) because they're operational artifacts, not skill code; matches where MAC matrices and other domain operational state already lives.

3.11 (Unprompted) Critic axis count vs return-time tradeoff

Question: Lloyd ran 20 critic shards in parallel. RDCO domains likely want 3-7 axes (frontmatter, RDCO-mapping, cross-links, voice, sponsor-disclosure, ...). How is the axis count chosen per domain?

Options:

A. Hard cap at 5 axes per domain. Pros: bounded parallel cost; forces axis prioritization. Cons: arbitrary; some domains genuinely need more.
B. No cap, declared per-domain YAML. Pros: flexible. Cons: easy to bloat to 20 axes with diminishing returns.
C. Soft guideline of 3-7 in the schema with a warning if a config declares >7, no hard block. Pros: discipline by default, escape hatch when warranted. Cons: warnings get ignored.

Recommendation: C. Lloyd's 20 was for visual rendering where axes were genuinely orthogonal (diagram type). RDCO domain axes correlate more (frontmatter ↔ cross-links ↔ RDCO-mapping all touch the same artifact), so fewer axes are warranted. 3-7 is the soft target.

4. Open questions for the founder

Below are the choices where I genuinely think the founder's judgment is needed before locking, ordered by load-bearingness:

Bootstrap shape (section 3.7). Recommendation D treats the founder as the critic for the one-time bootstrap. Is the founder willing to be the bootstrap critic, or does he want option B (toy pipeline first) for additional safety? This determines whether we start building seats this week or build a haiku-generator toy first.
Canonical-set representation (section 3.5). Recommendation D is a hybrid (structural YAML + reference-artifact folder). Does the founder agree that voice/judgment axes require reference exemplars, or does he want to push for fully-structural axes (option B) to keep the critic deterministic? This is the biggest "RDCO-specific gap from Lloyd's case study" question.
First domain to ship through the pipeline (section 3.7 implies, not explicit above). The decision-page outcome named /build-website-discovery as the first worked example, currently Blocked. Confirm this is the right first-domain pick vs alternatives (e.g. /build-mac-matrix would be the most thesis-defining domain; /build-sc-article would be the highest-volume target).
Decision-page click-back as v1 vs v1.1 (section 3.9). Defer to v1.1 keeps scope tight, but the founder has used the click-back wire heavily today — if he expects it from day one, we should pull it forward.
Axis-fragment registry path (section 3.8). Confirm ~/rdco-vault/01-projects/skill-pipelines/axes/ is the right location vs ~/.claude/skills/pipeline-critic/axes/ (closer to the consumer) or ~/rdco-vault/06-reference/critic-axes/ (alongside other reference material). This is a minor question but locking it now prevents path churn later.

5. What lands after this doc is approved

YAML schema for per-domain configs (configs/<domain>.yaml) and for reusable axis fragments (axes/<name>.yaml) — committed to ~/rdco-vault/01-projects/skill-pipelines/SCHEMA.md.
SKILL.md drafts for the four utility seats: pipeline-spec-author, pipeline-test-author, pipeline-code-author, pipeline-critic.
First domain workflow SKILL.md draft — build-website-discovery/SKILL.md (or whichever domain the founder picks in open question 3), wiring the 4 utility seats together.
Reference set for the first domain — 3-5 known-good artifacts curated into references/website-discovery/ plus the structural YAML at configs/website-discovery.yaml and axis fragments referenced.
Smoke test — one end-to-end run of /build-website-discovery <toy-input> exercising all 4 seats, the parallel critic fan-out, the convergence loop, and the per-run scratch directory. Output: a run log at runs/<domain>-<timestamp>/ plus a one-page postmortem on what the pipeline got right vs what needs iteration. This validates the architecture before scaling to MAC, SC-article, and future domains.

Doc status: draft-for-founder-review. Lock the load-bearing choices, answer the 5 open questions, and item 1 (schema) is ready to land within the same session.