Skip to content
GRPNR.

R2 — Prior internal decisions & evidence relevant to Atlas

2026-07-18. Compiled for plan 003 (Atlas intelligence layer) from plan 001 (factory apps validation, decided), plan 002 (work-ledger, decided), plan 004 (fleet monitor, decided), and the dossier/research base those plans rest on. Atlas is the proposed EXPANSION of the already-decided factory app #3 (question-triage) into a broader “intelligence and communication layer.” This file collects what already exists as ground truth so plan 003 does not re-derive or silently contradict it.

Source files read: plans/001-factory-apps-validation/00-SYNTHESIS.md, plans/002-work-ledger-product/README.md + 01-initial-recommendation.md, plans/004-fleet-monitor/01-initial-recommendation.md, research/00-dossier.md, research/12-collab-split-and-fleet-monitor.md, analysis/legacy/SYNTHESIS.md.

(a) Verbatim / near-verbatim decided constraints that bind Atlas

These are DECIDED (plan 001 shipped, confidence high on portfolio shape), not open for Atlas to relitigate — Atlas must fit inside them or explicitly argue for a re-decision.

  1. Zero-PR v1, named explicitly, twice. Plan 001 architect addendum point 3: “Triage v1 = zero PRs: existing INFORMATION_REQUEST + assigneeGroupSlug ‘agent-questions’ queue. TaskType enum PR demoted to optional v2. Real negotiation = inbox pollution, solved by dedup/rate-limit + queue filter.” The per-app verdict table (row 2) already softened the original dossier’s “Tomas’s tasks service gets ONE negotiated PR” down to zero-PR after the architect review. Pre-mortem item 4 in plan 001 independently reinforces this: “Triage shipped clever, not useful… naive-first ordering is in v1 by decision, not preference.”
  2. Internal plane, CODEOWNERS-partitioned lane. Plan 001’s recommended architecture places QT[triage svc] inside the internal plane alongside work-ledger and the dual-run harness, under a Robert-DRI CODEOWNERS partition (assumption A1), with a named fallback (A-lite: Robert-owned repo, API-only) if Tomas doesn’t grant the lane. Core plane stays Tomas-DRI, untouched.
  3. Factory-lane ask is capped and named. Plan 001 step 6: “Send research/14 answer… with the A1 ask embedded — the lane, OWNERSHIP.md, and the one TaskType PR as the only three asks.” Any Atlas proposal that expands the ask surface (new services owned by Tomas, new schema changes to tasks, new cross-plane event bridges) contradicts this unless re-negotiated. Also decided (addendum point 1): “no core→internal event path exists (decision log #36: ‘no cross-plane signal bridge yet’)” — so any Atlas feature assuming live event flow from core plane is currently false.
  4. Comm standards for anything Tomas-facing (from program context, echoed in the docs): English, plain, no em-dashes, receipts not adjectives, numbers carry MEASURED/MODELED/DARK/DESIGN passports. Plan 004 applies this explicitly in-UI: “four metrics that are true beat forty that are plausible… numbers carry their passport… per Tomas’s comm standards.”
  5. Naming discipline. Plan 002’s initial recommendation: “Never ‘ticket’, ‘task’ (collides with Zaruba’s tasks service), or ‘issue’.” Any Atlas glossary/doc layer must not reuse names already claimed by Zaruba’s core-plane vocabulary.
  6. “Teams to keep updated” do not exist yet (program context, confirmed by all three plans — every plan’s user list is Robert + fleet agents + Tomas as sole/occasional second human; no organization, no third stakeholder appears anywhere in 001/002/004).

(b) Evidence on question volume, duplicate ambiguity, interrupt cost at fleet scale

No measured (fleet-scale) data exists yet — everything below is MODELED or analogy-sourced, and the docs say so themselves.

  • Dossier §4 risk 3: “Stakeholder saturation — hundreds of questions/day vs ~101 contributors; no industry data exists on this.”
  • Research/12 §2 close: “Dedup/rate-limit/stakeholder-overload remains genuinely unsolved in public literature” — checked twice (dossier + research/12), same conclusion both times.
  • Dossier §1 risk framing: fleet review-pickup analogy — “AI-authored PRs wait 4.6× longer for review pickup, 32.7% acceptance vs 84.4% human” — used as the general “review/answer capacity is the constraint” evidence, not question-specific but the closest measured analog available.
  • Program context: Tomas is explicitly decision-bound (“more agents won’t help me”) — he is the single scarcest resource the whole triage/Atlas design exists to protect. Plan 004 formalizes this as “Tomas… as read-only daily-digest consumer — not a dashboard user”, i.e., even the fleet-monitor sibling was designed to minimize, not add to, his interrupt load.
  • Legacy synthesis §3/§4 gives a concrete generator of question volume once work starts: EOL/frozen-since-2017 code with dead owners (VIS frozen ~2013, orders frozen ~2017) “will generate ‘is this even alive/who owns this’ questions at volume” — a real, estate-specific source of ambiguity Atlas would have to route, distinct from generic engineering questions.
  • Plan 001 pre-mortem’s success metric for triage is explicit and falsifiable: “questions/unit flat after 4 weeks” is the failure signal; the fix specified is naive exact-match dedup shipped first, embeddings second (never the reverse).

(c) What prior research already rejected, and why

  • HumanLayer — dossier §2: “the only candidate… is deprecated; replicate its two primitives” (require_approval, human_as_tool). Rejected as a dependency (dead project), kept as a design reference for the two primitives only.
  • langchain-ai/agent-inbox — research/12 §“Question-triage tie-in”: “the only live off-the-shelf reference — worth a skim, still nets out build-thin on Temporal.” Rejected as a foundation because it’s LangGraph-coupled and doesn’t change the build-thin verdict; not rejected as worthless, just insufficient to avoid building.
  • Generic dual-run/parity products — plan 001 assumption A2: “No generic dual-run machinery exists yet beyond merchant-accounting oracles” (sibling app, not triage, but confirms the pattern: nothing off-the-shelf survives verification anywhere in this portfolio).
  • Work-ledger candidates (adjacent, same rigor Atlas should expect to be held to): plan 002’s open research questions explicitly test beads, Backlog.md, bare pgmq/SKIP LOCKED, and Temporal search-attributes + tasks svc + Grafana as “covers 90% for zero build” candidates — verdict pending in that plan’s own 06/11 docs (not read here), but the 001 verdict already commits to BUILD THIN, meaning the bar an alternative must clear is high.
  • Custom UI generally — repeated pattern across 002 and 004: “no custom web UI, kanban, or board view” (002), “the metric wall as primary UI; a kanban board… a control room” (004, explicitly removed from concept). Any Atlas UI/dashboard/portal ambition runs directly against this established anti-pattern-avoidance across every sibling app.
  • MBUS bridge as a standalone app — plan 001 verdict 9: DROP, “reverses Zaruba’s explicit rejection [E4] — fastest route to collision.” Relevant precedent for Atlas: standalone builds that shadow core-plane concerns get killed even when technically useful.

(d) Overlap risks with the three sibling factory apps

Atlas as described (docs, glossary, comms, progress updates, PLUS question triage/dedup/routing/write-back) collides with already-owned territory on nearly every axis:

  • Work-ledger owns “documentation of what’s changing” for work units: disposition rows (MIGRATED/DROPPED/DEFERRED/DEAD + owner + date, absorbing the decommission ledger), evidence links, cost/unit — i.e., the authoritative record of legacy-to-new state per unit. Atlas’s “documents legacy systems and the new monorepo” ambition overlaps directly unless scoped to stand on top of ledger data rather than duplicating it. Plan 002 explicitly reserves “evidence-file storage” and “cost roll-up dashboards” to the ledger/monitor, not to any new layer.
  • Fleet monitor owns “keeps teams updated on progress”: plan 004’s entire product is the attention-router/status list + daily digest to Tomas, and it already claims the “no metric wall, no control room, no kanban” territory Atlas would need to re-decide against if it grows a dashboard. The daily-digest mechanism for Tomas is already fleet-monitor’s, not Atlas’s, unless explicitly merged.
  • Question-triage (factory app #3) IS Atlas’s stated starting point — the expansion risk named in the task itself: v1 was scoped as a narrow dedup/rate-limit/write-back layer inside the internal plane using existing INFORMATION_REQUEST tasks, with a very tight zero-PR mandate and a naive-first sequencing discipline (pre-mortem-tested). Atlas’s stated scope (glossary maintenance, legacy/monorepo documentation, decision history, migration context, “teams”) is a large superset of that decided, narrow v1. Every additional surface Atlas adds is additional negotiated surface against the “only three asks” constraint and against the pre-mortem failure mode (“shipped clever, not useful”).
  • Dual-run harness / verification (sibling, not fully read here) owns evidence and parity data that any “documents what’s changing” layer would need to cite rather than re-derive — cross-reference only, not read in this pass.
  • ADR log / knowledge architecture is already assigned: research/12 §1 already establishes a shared ADR mechanism (MADR 4.0 + owner-domain + provenance footer, supersede-never-edit) living in monorepo-development, with both leads’ agents importing the same index via CLAUDE.md/AGENTS.md. Atlas’s “glossary/shared knowledge” ambition needs to be checked against this existing mechanism before proposing a new one — high risk of building a second, competing knowledge system.

Bottom line for plan 003: Atlas’s core expansion thesis (triage → documentation/comms/glossary layer) has no standing rejection yet, but it walks directly into territory three sibling decisions already claimed piece by piece (ledger = state/disposition record, monitor = attention/status/digest, ADR mechanism = decisions/knowledge), and its own stated starting point (triage) is bound by a zero-PR, naive-first, no-UI mandate that the expanded vision would need to explicitly defend continuing to honor or argue to change.