Journey — Dual-run parity harness

2026-07-18 · Stakeholder map + full journey analysis. Reads with 00-context-brief.md and initial-recommendation.md; do not re-derive facts already settled there.

This is an internal product with no buyers or churn in the SaaS sense. Every section below is reinterpreted for that reality and says so once, here, rather than per-section: “buyer” = program-gate approval (Tomas’s lane sign-off + Robert’s investment call), “pricing” = engineer-days + agent-token spend charged against Robert’s lane, “churn” = agents/builders routing around the harness (bypass), “procurement” = none — skipped, not scaled down, because no external vendor relationship exists for the harness itself (tool-landscape purchase decisions, if any, are initial-recommendation.md §13’s problem, not this document’s).

1. Stakeholders

Only stakeholders with a genuine, evidenced role are listed — no invented personas, no generic “end user” filler.

Stakeholder	Role	Influence
Fleet agents	Primary user (machine)	High — the harness’s real traffic source; a bypassable gate is a gate that doesn’t exist
Strike-unit builders (4)	Primary user (human)	High — own the exception path; every DIVERGED that isn’t obviously noise lands on them
Tomas Zaruba	Buyer/approver — lane + oracle boundary	Decisive — owns scope-contract, the shadow-checkability classification (YES / COMPARE-ONLY / NO), and the existing 3-oracle reconciliation the Orders adapter must generalize, not replace
Robert	Buyer/approver — investment	Decisive — harness is Robert-lane spend; he decides how many weeks it gets before falling back to impact-selected tests
QSA/SOX auditors	Evidence consumer	Gate-holding but passive — DONE row 9 requires their sign-off; they consume evidence bundles, they do not operate the harness
Security review	Evidence consumer / gate	Gate-holding — PII/PCI fixture masking and retention need their sign-off before any Orders-chain fixture leaves the legacy-runtime lab (D5: every Orders-chain repo touches PII/PCI somewhere)
Robert’s fleet ops	Operator	Medium — runs the legacy-runtime lab, the recorder, the Grafana panel; keeps fixtures fresh

1.1 Fleet agents (primary, machine)

Goal: claim a work-ledger unit, get a verdict fast enough to keep moving, promote to PR lane on PARITY.
Incentive: verdicts are the only path to promotion — there is no separate manual-review lane for agents to prefer instead (D4: no such alternate surface exists in the repo today, so once built, the gate is real by construction, not by policy).
Current behavior: none yet — the gate doesn’t exist. Baseline behavior today is agents self-reporting test-suite-green, which is exactly the “vibes at 99.999% stakes” failure mode initial-recommendation.md §10 names.
Fears: none in the emotional sense — but the harness must fear for them: token burn on phantom divergences (noise) is the single risk that turns a helpful gate into a tax agents route around.
Objections (simulated, principle-based): “verify” adds latency to every unit; a slow or flaky harness is worse than no harness because agents will retry-loop against it.
Decision criteria: deterministic, idempotent output (same input replay yields the same verdict every time — this is also the harness’s own self-test, initial-recommendation.md §11).
Definition of success: PARITY verdict, evidence link attached, unit promoted, zero manual intervention.

1.2 Strike-unit builders (primary, human)

Goal: ship the Orders adapter and downstream domains without the harness becoming their bottleneck.
Incentive: program bonuses gate on DONE rows the harness’s evidence feeds directly (reconciliation ≥99.999%, error ≤ baseline +0.1pp are production telemetry, not harness output — but row 8’s seed, the billing-events feed, is literally the harness’s read point per D4).
Current behavior: hand-rolled reconciliation (reconciliation.service.ts, crossCheckRange) for exactly one domain slice — the only precedent to build from, not a green field (D4 §b).
Fears: a DIVERGED storm eating a sprint in noise triage instead of real bugs; a harness whose false-DIVERGED rate is unknown because — per D6 Q2 — no comparable tool (Diffy included) ever published one.
Objections: “we already have oracle code that works — don’t make us rewrite it to fit your interface.” Resolution: the adapter wraps crossCheckBillingFeed/computeReconciliation almost verbatim (D4 §b) — this objection is answered by design, not by argument.
Decision criteria: a normalization-rule decision must be faster to make than to skip; if adding a rule takes longer than manually re-checking the diff, builders will stop using the mechanism.
Definition of success: DIVERGED bundles are rare enough, and clear enough, that triage is minutes not hours.

1.3 Tomas Zaruba (buyer/approver — lane + oracle boundary)

Goal: every use case that’s shadow-checkable (per his own R4 table, D4 §c) gets a machine-checked verdict before it’s counted DONE; the harness never invents scope his audit didn’t authorize.
Incentive: the program’s bonus structure depends on legacy actually turning off, provably.
Current behavior: owns the only reconciliation machinery in the repo and the only three-way shadow-checkability taxonomy (YES / COMPARE-ONLY / NO) in any doc; has never used the words “harness,” “parity kernel,” or “shadow-tap” himself (D4 §c) — this vocabulary and its implementation are Robert’s decision to make, inside a scope Tomas already defined.
Fears: the harness scope-creeping into use cases he already classified NO (verified another way — PII scan, PCI audit, operator drill) and duplicating audit work; the harness claiming authority over the money-chain’s final gate when his own docs (D4 §c, line 74) tag the ≥99.999% target as DESIGN, not yet MEASURED — i.e. he knows it isn’t proven yet either.
Objections: “COMPARE-ONLY rows (row 2, collect payment) can never become live dual-run — a capture cannot run twice. Don’t build a mode that assumes it can.”
Decision criteria: the adapter must map 1:1 onto his shadow-checkability classes, not invent a fourth; any new Encore-hosted harness component must respect the core/internal plane boundary and proposal-endpoint pattern (D4 §d) — no exceptions negotiated after the fact.
Definition of success: rows 24/25 (order money → ledger, voucher lifecycle → ledger) are proven “YES — this IS the reconciliation harness” (D4 §c) using the existing oracle pattern, generalized, not reinvented.

1.4 Robert (buyer/approver — investment)

Goal: the harness proves legacy-off fast enough that it doesn’t become the schedule itself (pre-mortem #2, context brief).
Incentive: program economics — $6.7M all-in, M4 ≈ $0.9M; harness effort is weeks, staged per flagship gate, not months.
Current behavior: wrote the initial recommendation as the position to be attacked; explicitly reserves the right to fall back to the ~70% impact-selected-test result (D6 Q7: single-study, uncorroborated, but the stated fallback) if the harness overruns.
Fears: second-adapter cost >2× first adapter cost (the detection trigger for “harness doesn’t generalize” already named in 001’s risk register) going unnoticed until it’s already sunk.
Objections: none simulated here — Robert is the author of the position being challenged, not a persona to advocate for; his real objections surface in his own review of this plan, not in a fabricated voice.
Decision criteria: cap investment per flagship; kill or freeze the generalization ambition the moment the 2× signal fires.
Definition of success: Orders’ 10-row DONE checklist closes on schedule with the harness’s evidence bundles as load-bearing proof for at least rows 4 and 9.

1.5 QSA/SOX auditors (evidence consumer)

Goal: sign off DONE row 9 on evidence that survives their own falsification attempt, not on trust.
Incentive: their professional liability is the sign-off itself — evidence has to be replayable by someone who wasn’t in the room.
Current behavior: unknown/DARK — no auditor has touched this program’s artifacts yet (no evidence in any discovery note of auditor engagement to date); treat their requirements as assumption, not measured, until Tomas’s compliance track confirms them.
Fears (assumption, not evidenced): a report that hides its exclusions — an unreadable normalization ledger is functionally the same as no normalization ledger to an auditor.
Objections (assumption): “show me the replay recipe, not just the verdict” — this is exactly initial-recommendation.md §7’s Rams-lens requirement (falsifiability), independently motivated by audit practice, not just design taste.
Decision criteria: every stated number carries source + window + confidence (Zaruba’s evidence law, binding per context brief) — auditors are the sharpest-toothed consumer of that law.
Definition of success: a cold read of the evidence bundle, months later, reproduces the same verdict.

1.6 Security review (evidence consumer / gate)

Goal: no PII/PCI leaves the legacy-runtime lab unmasked, ever, in any fixture.
Incentive: GDPR/PCI exposure is a program-ending risk, not a schedule risk — this gate is qualitatively different from every other stakeholder’s.
Current behavior: D5 §b: every Orders-chain repo touches PII or PCI somewhere (card tokens/SEPA in billing-record-service, GDPR erasure across users-service/consumer-data/orders_mbus_client, device fingerprints in fraud calls) — this is not a future concern, it is day-one scope for the very first adapter.
Fears: masking that’s “good enough for demo” shipping to a shared fixture store; D3’s finding that PII masking of HTTP fixtures (as opposed to DB rows) has no free off-the-shelf tool — GoReplay’s masking is a paid Pro feature — means this is genuinely unsolved tooling, not a checkbox.
Objections: “fixtures don’t leave the lab until sign-off, full stop” — this is a hard gate, not a negotiable SLA.
Decision criteria: masking coverage proven per fixture class, not asserted once for the whole harness.
Definition of success: an Orders-chain fixture can be shown to a third party without a PCI/GDPR incident.

1.7 Robert’s fleet ops (operator)

Goal: legacy-runtime lab images stay bootable and fixtures stay fresh; the Grafana panel stays truthful.
Incentive: operating cost is charged against the same Robert-lane budget as everything else — cheap operation is the job.
Current behavior: OTel/Grafana local-first fleet monitor already exists for agent orchestration (context brief); extending it with a parity-coverage/divergence-rate panel (initial-recommendation.md §6) is additive, not new infrastructure.
Fears: the highest-risk lab tier — Ruby 1.9.3/JRuby 1.7, Rails 3.2 hand-patched (voucher-inventory-service, D3 + D5 §c) — going stale because nobody re-boots it between recording sessions, and the manifest-v1 Docker deprecation issue (D3, unresolved as of the research date) breaking pullability entirely with no warning.
Objections: “don’t hand us a sixth distinct pinned runtime combination with no reuse (D5 §c) and expect day-one uptime.”
Decision criteria: per-repo lab setup cost stays near the modeled 2–5 engineer-days for a first-of-stack repo (D3, MODELED) and drops for follow-on repos reusing a solved combination (D3, inference-by-analogy, not sourced — flagged as such).
Definition of success: a lab image boots on demand, records a fixture batch, and the fixture batch passes the harness’s own self-replay-yields-PARITY test (initial-recommendation.md §11) before it’s trusted for anything else.

2. The core journey

One row per stage. “Owner” is who is accountable for the stage not stalling.

Stage	Goal	Action	Friction	Failure state	Metric	Owner
Domain onboarding	Stand up one domain’s lab image, recorder, adapter	Fleet ops pins the EOL image, boots it, wires the recorder proxy or shadow-tap; a builder writes the adapter wrapping the domain’s oracle(s)	Highest-risk stacks (Ruby 1.9.3/JRuby 1.7, Rails 3.2 hand-patched) have an unresolved Docker manifest-v1 pull risk and a RubyGems TLS 1.2 floor blocking fresh installs (D3)	Lab never boots; domain onboarding stalls indefinitely	Setup cost per repo, MODELED 2–5 eng-days first-of-stack (D3)	Fleet ops
Fixture recording	Capture ground-truth traffic across all applicable classes (sync HTTP, async MBUS+outbox, batch/cron)	Recorder proxy or shadow-tap runs against the booted legacy lab; fixtures written content-addressed	Batch/cron traffic is structurally uncapturable by an HTTP proxy — needs DB-transaction-log tailing or job instrumentation (D5 §d.3); it is DARK for Orders’ own Resque jobs today	Fixture set covers only sync HTTP; batch-surface regressions ship invisible, “the invisible surface that kills rewrites”	Fixture-class coverage vs. MODELED ~50–60+ classes for Orders alone (D5 §d)	Fleet ops + builder pairing
Agent claims unit	Pick up one work-ledger unit to rebuild	Agent reads unit spec, writes/edits code	None specific to the harness at this stage — ordinary fleet-claim mechanics	Agent claims a unit the harness cannot yet verify (no adapter for that domain)	Claim-to-verify latency	Fleet agent
Harness verify	Produce a machine-checked verdict for the unit	`harness verify <unit>` replays recorded traffic against legacy lab AND the new service, normalizes, diffs	Noise (timestamps, generated IDs, ordering, float formatting) drowning signal — the harness’s own named biggest usability risk (`initial-recommendation.md` §10); no comparable tool has ever published a false-positive rate to benchmark against (D6 Q2)	False DIVERGED on a self-replay (record → replay same legacy instance yields non-PARITY) — the harness’s own falsification recipe failing on itself	Self-replay PARITY rate (target: 100%, this is the floor, not a KPI to trend)	Kernel (automated)
Verdict	Emit PARITY / DIVERGED(counterexample) / UNVERIFIABLE(reason)	Kernel writes a verdict row to work-ledger	No verdict/question-minting surface exists anywhere in the repo today (D4 §a.3) — this row-type is 100% new build, not an integration	Verdict written but not actually gating anything downstream (see §3 Agent bypass attempt)	Verdict latency (must not make agents retry-loop)	Kernel (automated)
Promote-or-block	Gate PR-lane entry on the verdict	PARITY → unit promoted with evidence link; DIVERGED/UNVERIFIABLE → unit blocked, question minted	The gate has to be structural (no manual override path that isn’t itself audited) — nothing like it exists today; the closest existing “unit of work with a status” table, workflow-management’s `workflow_executions`, is Temporal-run-shaped, not agent-task-shaped, so it cannot be reused as-is (D4 §a). The question-minting half of a block reuses Tasks’ `INFORMATION_REQUEST`, but that requires an owning Temporal workflow run and has no `assigneeGroupSlug` registry (D4 §a.4)	Unit reaches PR lane without a verdict row — see §3, this must be made structurally impossible, not policed	% units promoted without human touch	Kernel + work-ledger
Divergence triage (human)	Decide “real regression / acceptable difference / add normalization rule”	Builder opens the evidence bundle, reads the smallest counterexample first (Ive-lens ordering, `initial-recommendation.md` §7)	Triage volume overwhelms builders if normalization lags fixture growth	Builders stop reading bundles (trust collapse → bypass, `initial-recommendation.md` §10)	Median triage time per DIVERGED	Strike-unit builder
Normalization-rule decision (auditable)	Record why a field/difference is ignored, permanently	Builder adds a rule to the normalization ledger with rationale	Rules added ad hoc without rationale erode the falsifiability the auditors need	A rule silently suppresses a real future regression	Normalization-ledger entries with stated rationale / total entries (target: 100%)	Strike-unit builder, logged not deleted
Parity evidence feeds DONE rows	Evidence bundles become the receipts DONE rows cite	Reconciliation-oracle results and verdict history roll up into the Orders 10-row DONE checklist	Row 8’s seed (billing-events feed) already exists and is already used by Zaruba’s own reconciliation (D4 §a.1) — the harness must not duplicate it, must consume it	Harness invents a parallel feed instead of reading the existing one	DONE rows citing harness evidence / 10 total	Tomas (accepts), harness (supplies)
Domain retires	Harness moves on to the next flagship	Domain’s dual-run turns OFF per M4 schedule; lab image and fixtures archived, not deleted (falsifiability requires replay-ability after the fact)	Archived fixtures still carry PII/PCI — retention policy must survive retirement, not lapse with it	Fixtures deleted or lost, DONE-row evidence becomes unfalsifiable in hindsight	Domains retired on schedule / domains attempted	Robert (investment call), security review (retention)

3. Alternate journeys

Happy path. Domain onboarded once; fixtures recorded once, refreshed on a cadence; agent claims unit → verify → PARITY → promote, unattended, in the common case. This is the only path where the harness pays for itself — every alternate path below is a cost the design must bound, not eliminate (some, like divergence triage, are inherent to the product).

New domain onboarding fails (lab won’t boot). Concrete, evidenced example: voucher-inventory-service is Ruby 1.9.3-on-JRuby-1.7.27, Rails 3.2 hand-patched off a git branch, not a released gem (D5 §c) — the single hardest boot in the estate per the legacy SYNTHESIS. Resolution path: fleet ops treats this as a MODELED 2–5 eng-day sink, not a blocker to escalate; if it exceeds that by a wide margin, the domain falls back to the impact-selected-test fallback (D6 Q7, ~70% figure, single-study caveat attached whenever cited) rather than stalling the flagship. Decisive rule: no domain waits on a perfect lab boot past its budgeted setup window; it either ships degraded (impact-selected tests only) or the flagship schedule slips, publicly, per the program’s own week-6 rule.

Missing/poor fixtures (COLD capability, no traffic). A capability with no recorded traffic cannot produce a verdict — it is UNVERIFIABLE by construction, not a bug to fix in the kernel. Resolution: UNVERIFIABLE is a first-class verdict state, not a crash; it blocks promotion exactly like DIVERGED but routes to a different triage queue (record more traffic vs. explain a divergence) so builders don’t burn time debugging a non-existent diff.

False DIVERGED storm (noise). The named top usability risk (initial-recommendation.md §10), directly evidenced by D6 Q2: even Diffy’s own creators never published a false-positive rate for their statistical noise-cancellation mechanism, so the harness cannot borrow anyone else’s track record — it has to earn its own. Resolution, in order: (1) the self-replay-yields-PARITY test is the pre-ship gate, not a nice-to-have — a kernel version that fails its own self-test never reaches agents; (2) normalization-ledger rules absorb known noise sources (timestamps, UUIDs, ordering) from day one, not as a post-hoc patch; (3) if storm conditions recur despite (1) and (2), the adapter is paused for that domain, not tolerated — a paused adapter is cheaper than a fleet that has learned to ignore verdicts.

UNVERIFIABLE unit. Distinct from DIVERGED: the harness could not produce a verdict at all (missing fixture, lab down, ambiguous oracle mapping — e.g. the third “contract check” oracle Tomas’s own design doc names but that has zero implementation, D4 §b). UNVERIFIABLE blocks promotion the same as DIVERGED but must never be silently treated as PARITY by a retry loop — this is a correctness requirement on the kernel, not a UX nicety.

Permission/PII blockage. A fixture is recorded but cannot leave the lab because masking coverage isn’t proven for that fixture class — e.g. any billing-record-service fixture carrying tokenized PANs or SEPA details (D5 §b). Resolution: security review’s sign-off is a per-fixture-class gate inside onboarding, not a one-time whole-harness approval; D3’s finding that HTTP-fixture PII masking has no free off-the-shelf tool means this gate has real engineering cost attached (build or license masking), not just a review meeting.

Agent bypass attempt (unit reaches PR lane without a verdict). This must be structurally impossible, and today it is not enforced anywhere — D4 §a.3 confirms no verdict/question-minting surface exists in the repo at all. Where it must be enforced: work-ledger’s promotion transition has to require a verdict-row foreign key before a unit can flip to PR-lane-eligible state, checked at the data layer (a DB constraint or an Encore proposal-endpoint validation that rejects the transition without it, per the plane’s proposal-endpoint pattern, D4 §d.4) — not a convention agents are expected to follow, not a CI check that can be skipped, not a lint rule. This is new build, called out explicitly so it does not get silently dropped from the PRD’s functional requirements: the promotion gate is the harness’s only truly load-bearing structural claim; every other property (accuracy, speed, coverage) degrades gracefully, this one cannot.

Harness retirement/offboarding per domain. M4 turns the money chain OFF; the domain’s dual-run stops running live, but its evidence bundles and normalization ledger remain queryable — QSA/SOX sign-off (row 9) can be asked for years after the fact, and Zaruba’s own audit law requires falsifiability, not “trust us, it passed once.” Resolution: retirement archives (lab image definition, fixture set, verdict history, normalization ledger) together as one unit, does not delete PII-bearing fixtures without security review’s retention sign-off, and never reuses the domain’s work-ledger unit IDs.

4. Journey-stage capability requirements → PRD functional requirements

Each row is a capability the journey above demands; each maps to a functional requirement the PRD must state explicitly (not left implicit in the kernel design).

Journey stage	Capability required	→ PRD functional requirement
Domain onboarding	Boot a pinned EOL image reliably, with a bounded setup-cost budget	FR: legacy-runtime lab must support N distinct pinned runtime/framework images (6 for the Orders chain alone, D5 §c) with per-repo boot verified before recording starts
Domain onboarding	Recorder covers all 3 traffic classes, not just sync HTTP	FR: recorder must have a distinct capture mechanism per class — proxy for sync HTTP, shadow-tap for MBUS+outbox, DB-transaction-log tailing or job instrumentation for batch/cron (D5 §d.3)
Fixture recording	PII/PCI masking proven per fixture class before release from the lab	FR: masking coverage is a gate attribute of a fixture class, not a global flag; no off-the-shelf tool solves this for HTTP fixtures (D3) — build or license explicitly scoped
Harness verify	Deterministic, idempotent verdict on identical input	FR: `harness verify` must be pure given (fixture, candidate) — no wall-clock or environment leakage into the diff
Harness verify	Noise normalization as kernel v0, not polish	FR: normalization-ledger mechanism ships with the kernel’s first version, with a documented default set (timestamps, UUIDs, ordering, floats) before any real domain onboards
Harness verify	Self-test the kernel against itself	FR: CI gate — kernel version cannot ship unless self-replay (record → replay same legacy instance) yields 100% PARITY
Verdict	Three-state verdict, not boolean	FR: verdict type is `PARITY \| DIVERGED(counterexample) \| UNVERIFIABLE(reason)` — no existing type in the repo has this shape (closest is `ReconciliationReport.balanced: boolean`, D4 §a.3); must be built new
Verdict	Expected-no-op state distinct from divergence	FR: verdict interface must carry a third bucket beyond posted/gap — an “expected, not posted” case (modeled on `ConsumptionStatus`’s `received`-but-correctly-unpublished class, D4 §b) or every lifecycle event misclassifies as DIVERGED
Promote-or-block	Structural gate, not convention	FR: work-ledger promotion transition requires a verdict-row reference, enforced at the data/proposal-endpoint layer — see §3 Agent bypass
Divergence triage	Evidence bundle ordered smallest-counterexample-first	FR: evidence bundle rendering follows the Ive-lens ordering already specified in `initial-recommendation.md` §7 — restated here as a hard requirement, not a suggestion
Divergence triage	Question minting routes to a human/agent group	FR: triage needs an `assigneeGroupSlug` registry (`interfaces/tasks.interfaces.ts:52-56`) — none exists today (D4 §a.4); this is new build, and the mint path must not require Tasks’ Temporal-workflow-stamp coupling unless the harness is willing to own a wrapper workflow
Normalization-rule decision	Rule changes are themselves audited	FR: normalization-ledger writes are append-only with rationale and author, never silent edits — auditable scope decisions per the context brief’s own framing
Parity evidence → DONE rows	Reuse the existing billing-events feed, don’t duplicate it	FR: Orders adapter’s read path is `_billingEventsFeed` (`_billingEventsFeed.controller.ts:1-38`, `GET /order/internal/billing-events`, keyset-paginated, `expose:false auth:false`) — the adapter consumes this, it does not invent a parallel feed (D4 §a.1)
Parity evidence → DONE rows	Any Encore-hosted verdict-row write respects the plane boundary	FR: verdict-row writes into Core-owned tables from outside Core go through a Core proposal endpoint (submit → validate → apply/reject → audit log) — no direct table write, ever (D4 §d.1, d.4)
Domain retires	Archived evidence remains queryable and falsifiable	FR: retirement archives lab image definition + fixture set + verdict history + normalization ledger as one retained unit; PII-bearing fixture retention requires security review’s sign-off, separate from the retirement action itself

Open questions

Does the ≥99.999% ledger-reconciliation DONE row require live dual-run machinery, and if so, whose lane is it? D6 Q4: every credible real-world example of financial-grade parity found (Uber, Stripe) uses live/continuous mechanisms for the final gate, not recorded-fixture replay alone; no counter-example was found. This is an open design escalation, not resolved by this document, and belongs to Tomas and Robert jointly (context brief’s own open question #2).
What is the actual false-DIVERGED rate the kernel will produce on real Orders traffic? No comparable tool (Diffy included) has ever published one (D6 Q2); the self-replay test is a floor, not a substitute for measuring this on live fixture volume once the Orders adapter exists.
Who signs off the assigneeGroupSlug registry and Tasks-workflow-stamp question-minting design — D4 §a.4 confirms neither exists today; this is a build decision, not a research gap, but it is not yet assigned an owner in any doc read for this plan.
What is QSA/SOX’s actual evidence-bundle requirement? Section 1.5’s stakeholder profile is built on assumption, not measured engagement — no auditor has touched this program’s artifacts per any discovery note. Confirm before the evidence-bundle format is finalized in the PRD.
Exact Resque/Sidekiq job-class inventory for orders, users-service, voucher-inventory-service remains DARK (D5, open items) — the batch/cron capability requirement in §4 cannot move from MODELED fixture-class estimate to a scoped build task until this repo-level grep is done.
Does the harness need to own a wrapper Temporal workflow to mint triage questions, or is that structurally Zaruba’s plane’s responsibility? D4 §a.4/e flags this as unresolved even inside Zaruba’s own repo, not just externally.