Skip to content
GRPNR.

07 — UX/UI Specification: Atlas

2026-07-18. Written against 01-initial-recommendation.md (the recommendation under test) and evidence packets R1/R2/R3/R4/R5/R6/R7/R8. Doc-writing convention, matching plan 004’s precedent: VERIFIED (source+date, checked this pass), PRIOR-RESEARCH (sourced to an earlier dated doc or evidence packet, not rechecked today), DESIGN (a specification choice made in this doc, not a measurement), ASSUMPTION (inferred, not confirmed anywhere, flagged so it isn’t mistaken for a decision).

This product has no screens. Its UX is a task-completion form Tomas already knows, a handful of markdown files agents already know how to read, and a few lines inside a digest another product already sends. The job of this document is to specify those objects with the same rigor a screen spec would get — schemas, not mockups — and to say plainly everywhere Atlas’s ambition collides with a sibling plan’s already-decided territory.

Where this doc disagrees with or sharpens 01, stated up front, not buried:

  1. The write-back destination is not core plane. 01 says an answer “lands as a diff (docs/skills/GLOSSARY.md/decision record)” without saying which repo. R1 confirms the only existing docs corpus (_documentation/, bundled by pnpm docs:sync into the core-plane docs service) is core-plane content, and core plane is human-gated — every write-back there would be a Tomas-reviewed PR, which recreates the exact review bottleneck Atlas exists to remove, and adds a new ask beyond the single baseline ask already sent (R2 §a.3). §2 puts Atlas’s glossary and decision records inside Robert’s own internal-plane lane instead, self-mergeable, zero new asks against Tomas. Cost, named plainly: it will not appear in Zaruba’s GET /docs/search or the MCP docs tool until someone negotiates that as an additional ask (numbered from 2 under the corrected baseline). Accepted for v1, flagged as a real IA tax in §7.
  2. Atlas does not get its own digest. 01’s judgment table says “digest to GChat” as if Atlas owns the channel. R2 §d is explicit that fleet monitor already owns “keeps teams updated on progress… daily digest to Tomas” (plan 004 §3.5, already specced). A second daily message from a second product is exactly the “communication layer” bloat 01 itself wants scrutinized. §3.3 specs Atlas as rows fed into fleet monitor’s existing digest, not a standalone send.
  3. Atlas does not need a queue-viewing surface for Robert. 01 implies routing visibility might need building. It doesn’t: GET /tasks?assigneeGroupSlug=agent-questions&status=pending (R1 §1, the doc comment literally calls this “a review queue”) is already a working query, and whether fleet monitor’s own Queue overlay (004 §3.2) should also render it is an open integration question for 10-architecture.md, not something this doc should silently assume resolved. Flagged, not decided, in §4.
  4. “Zaruba’s existing tasks UI” is an unconfirmed assumption, not a fact. R1 verified the tasks backend endpoints in full; no frontend route for completing a task was found anywhere in the substrate read. §3.2 specs the answer form against the backend contract either way, with the frontend-exists case as primary and a named fallback if it doesn’t.
  5. Decision records must not cite or live inside reasons-and-decisions/. That directory is out of bounds for this research pass by standing instruction. It is also the wrong destination architecturally even setting that aside — it is Tomas’s core-plane running log, and writing Atlas-domain decisions into it would be exactly the core-plane PR stream point 1 above rejects. §2 uses research/12’s proposed MADR-style mechanism instead, hosted in Atlas’s own lane.

1. UX vision

Intended feeling, asker agent: instant certainty. Either the corpus already answers the ambiguity (search hit, zero interrupt, product worked and nobody saw it work) or a well-formed question is now filed, resuming is guaranteed, and the agent can park the thread and move to other work with a concrete handle, not an open-ended wait. The bad feeling this prevents is uncertainty about whether the question even landed — a raised hand that vanishes into a chat scrollback is the single most-cited chat-based failure mode in this program’s own prior notification-service decision (R1 §3: legacy’s Chat/Sherlock triage gateway was deliberately not ported).

Intended feeling, Tomas: “asked once, well-formed, never twice.” He should never receive a question missing the context he’d have to chase down before answering, never receive the same question twice in different words, and never wonder later whether his answer is still the standing one. This is the direct design response to the one verbatim fact this whole plan rests on — “víc agentů mi nepomůže” (more agents won’t help me, program context) — every field forced at capture time exists only to make this true.

Time-to-first-value:

  • Tomas: effectively zero. He is not onboarding to a new product — he completes a task in whatever surface he already completes tasks in (§0 point 4’s caveat applies: this is only true if that surface already exists). This is a genuine strength worth stating plainly, not just a constraint: the value of “no new human UI” is that adoption cost for the one truly scarce person is zero.
  • Asker agent: bounded by whichever half of the loop resolves it. Corpus-hit path is instant (a grep). Corpus-miss path is bounded by Tomas’s response latency, which nothing in this product controls or should pretend to control — DESIGN choice: never render a promised SLA on the asker side, because none exists (R1 §1 confirms SLA/escalation is explicitly not built and not planned for v1).
  • Week 1 reality, stated honestly: the corpus starts empty. Every question in week 1 is a corpus-miss by construction. Time-to-first-value for the corpus itself is not day 1 — it’s whenever enough answers have accumulated that a second asker’s search starts hitting. §6 treats this as the thing worth measuring, not faking.

Trust principles (binding, gate every surface in §3):

  • Provenance on everything. Every rendered answer, glossary entry, and decision record carries who decided it, when, and which question(s) it closes — never an unattributed fact.
  • Scope and expiry are mandatory on every Answer, not optional metadata. An answer with no stated blast radius is not a usable answer — 01 already names “Orders only vs program-wide” as the exact distinction that must never be silently dropped.
  • A stale answer is worse than no answer, and must say so. Serving an expired Answer as if it were current is the single worst thing this product can do to its own corpus — R8’s documentation-rot literature converges hard here: “once you encounter one outdated doc, you stop trusting all docs” (dev.to, R8 §1) — trust collapses to zero, it does not degrade gracefully. §3.6 specs the expired-serve-with-warning behavior as load-bearing, not cosmetic.
  • Numbers carry MEASURED/MODELED/DARK/DESIGN passports wherever Atlas renders a count (dup rate, corpus size, open-question count) — binding per the program’s comm standards, already applied in-UI by plan 004.

2. Information architecture — the object model and the file layout

Four objects. No fifth. Adding a category here is adding a new kind of ambiguity to route; resist it.

erDiagram
    QUESTION }o--|| CANONICAL_QUESTION : "attaches to (dedup)"
    CANONICAL_QUESTION ||--o| ANSWER : "resolved by (0 or 1)"
    ANSWER ||--o{ ARTIFACT_LINK : "renders into"

    QUESTION {
        string taskId "Zaruba INFORMATION_REQUEST task id"
        string askerSessionId
        json capturePayload "the 5-field schema, section 3.1"
        string status "pending, attached, answered"
    }
    CANONICAL_QUESTION {
        string id "Atlas-owned, internal plane"
        string canonicalTaskId "the ONE task Tomas actually sees"
        string matchMethod "exact, near-exact, human-confirmed"
        int attachedCount
    }
    ANSWER {
        string decision
        string rationale
        string scope "blast radius"
        date expiry
        string confidence "high, medium, low"
        string decidedBy
        date decidedAt
    }
    ARTIFACT_LINK {
        string artifactPath "GLOSSARY.md entry or decisions/NNNN-slug.md"
        string diffRef "PR or commit"
        date writtenAt
    }
  • Question = one raw ask from one agent session. Zero-PR mapping to the substrate (R1 §1): it is a Zaruba INFORMATION_REQUEST task, assigneeGroupSlug: "agent-questions", created via the existing POST /tasks/internal/create. The five capture fields (§3.1) render into description as structured markdown at mint time — no schema change to the tasks service, because none is needed; description already accepts arbitrary text.
  • CanonicalQuestion is the one Atlas-owned concept with no Zaruba equivalent — it lives in Atlas’s own internal-plane storage (new tables, Robert’s CODEOWNERS lane, assumption A1). It is the dedup cluster: N raw Questions attach to one CanonicalQuestion, and only the CanonicalQuestion’s task ever reaches Tomas’s queue. Duplicates never mint a second task Tomas sees — this is the entire point of the dedup layer and the reason “attach vs auto-resolve” (§4) is the single most important interaction decision in this spec.
  • Answer is what Tomas produces by completing the canonical task (POST /tasks/:id/complete, formPayload, R1 §1). Exactly one Answer per CanonicalQuestion in v1 — revisions supersede, they do not edit in place (§4).
  • ArtifactLink is the write-back pointer: which file(s) an Answer produced, and the diff/commit that did it. Without this, “written back into documentation” is a claim with no receipt — the whole point of provenance stamping (§1) is that this object always exists once an Answer closes.

File layout — deliberately outside _documentation/, per §0 point 1:

<internal-plane-app-root>/docs/atlas/
├── GLOSSARY.md              # single file, alphabetized, v1 — split only if it earns it
├── decisions/
│   ├── README.md            # index — one line per record, newest first
│   └── 0001-<slug>.md       # one file per decision, MADR-lite (§3.4)

(<internal-plane-app-root> is ASSUMPTION — R1 confirmed the core-plane app path apps/backend-encore-core-ts/ in detail but did not surface the internal-plane app’s own directory name. The pattern is expected to mirror it, e.g. apps/backend-encore-internal-ts/. Verify before implementation; nothing in this spec depends on the exact string.)

Discovery — naming convention + grep + index file, per the brief, no new tooling in v1:

  • The internal-plane’s own CLAUDE.md/AGENTS.md gets one import line pointing at docs/atlas/decisions/README.md and docs/atlas/GLOSSARY.md — the same mechanism every skill in this repo already uses to get picked up at session start (R1 §2, R4 §10-11: markdown-in-git addressed by filename convention, read directly by the agent’s own tools, is the industry-converged pattern for 2025-26, not a hosted product). Zero build.
  • Before filing a Question, an asking agent’s own skill instructs it to grep both corpora: _documentation/ (existing, via the docs MCP tool or GET /docs/search, R1 §5) and docs/atlas/ (plain file read/grep — no MCP registration needed in v1; adding one later is “a one-file-plus-registry-line procedure” per R1 §4 if grep ever measurably falls short). ponytail: plain grep, add an indexed search tool only when miss-rate data says grep isn’t enough — this is also 01’s own stated MVP boundary (no embedding/RAG until measured miss-rate demands it).
  • Naming discipline carried forward from R2 §a.5: never call any of this a “ticket,” “issue,” or “FAQ” — Question/CanonicalQuestion/Answer/GLOSSARY.md/decisions/ only.

3. Surfaces

3.1 Question capture schema

Rendered into the description field of the INFORMATION_REQUEST task at creation time. Five required fields, per the brief, no optional sixth in v1:

{
  "blockedOn": "string, one sentence — what decision or fact stops you",
  "searched": ["docs/atlas/GLOSSARY.md: no hit", "grep '<term>' _documentation/: no hit", "..."],
  "smallestUnblockingAnswer": "string — the minimum fact/decision that lets you resume, not a request for a design doc",
  "blastRadius": "string — which service/domain this affects, e.g. 'orders service only' or 'program-wide'",
  "quotedDataClass": "NONE | CODE_SNIPPET | SAMPLE_DATA | CUSTOMER_PII_OR_SECRETS"
}
  • searched is not decorative — it is what makes dedup possible at all (an agent that didn’t search first produces a question that can’t be checked against the corpus with any confidence) and it is the direct receipt that the corpus-check-first step actually happened, not a claimed one.
  • quotedDataClass (DESIGN, no external precedent found for this exact field — closest analog is standard data-classification practice, generalized here): if CUSTOMER_PII_OR_SECRETS, the write-back step (§3.5) hard-blocks automatic diffing — a human must manually redact before anything reaches GLOSSARY.md or decisions/. This is a gate, not a suggestion; it exists because the write-back corpus is exactly the kind of persistent, agent-readable store the memory-poisoning and context-rot literature (R8 §3) warns is dangerous to seed with anything sensitive.
  • Payload schema validation does not exist in Zaruba’s tasks service yet (R1 §1, explicitly not built) — Atlas’s own internal-plane layer validates this JSON before calling POST /tasks/internal/create, not the tasks service itself. Zero-PR is preserved because validation lives entirely on Atlas’s side of the call.

3.2 Answer form (inside Zaruba’s tasks UI — or its fallback)

Attached as the task’s formSchema, filled via formPayload on POST /tasks/:id/complete (R1 §1):

{
  "decision": "string: the ruling itself",
  "rationale": "string: why, in enough detail that scope makes sense later",
  "scope": "string: blast radius this answer covers, same vocabulary as blastRadius above",
  "expiry": "date | 'no-expiry', DESIGN default: 90 days out (borrowed from Guru's card-verification interval, R6 §3), Tomas can override",
  "confidence": "high | medium | low"
}

Fallback, named because §0 point 4 flags the frontend as unconfirmed: if no admin-UI route for completing tasks exists yet, the same five fields are filled via direct POST /tasks/:id/complete call — by Tomas himself (curl/a thin CLI), or dictated to an agent that makes the call on his behalf. The schema does not change; only the surface does. Verify frontend existence before committing to “inside the tasks UI” as a load-bearing claim in 12-prd.md.

confidence: low is not decorative either — it propagates to every rendering (§3.3, §3.4, §3.6): a low-confidence answer is never shown with the same visual/textual certainty as a high-confidence one, matching plan 004’s own rule that a guess must never carry the weight of a fact.

3.3 GChat digest — rows fed into fleet monitor’s digest, not a standalone send

Per §0 point 2. Atlas contributes a capped block to the existing digest (plan 004 §3.5’s skeleton), never its own message:

DECISIONS TODAY: 3 (2 program-wide, 1 orders-only)
  - feature-flag gating for new cart API: see docs/atlas/decisions/0014-cart-flag.md
  - VIS ownership: frozen since 2013, no active owner confirmed: 0015-vis-ownership.md
  - [1 more, full list: docs/atlas/decisions/README.md]

QUESTIONS: 2 open (1 duplicate cluster collapsed from 4 asks), 0 expired-served-with-warning

GLOSSARY: 1 new term (ORDERS_FREEZE), 0 revisions
  • Every count carries its passport inline (MEASURED, since these are direct ledger reads, no modeling involved) per the comm standard.
  • Capped at N most recent items (DESIGN, N=3-5 to start) plus a link to the full index — never let Atlas’s rows grow to crowd out fleet monitor’s own progress rows, which is the digest-becomes-noise risk named in §7.
  • No em-dashes, plain English, receipts not adjectives — same standard 004 already applies.
  • Zero events, zero decisions today renders as exactly that line, not an omitted section — omission reads as “nothing happened,” which plan 004 already established is worse than “we counted zero” (004 §3.5).

3.4 GLOSSARY.md entry format

One entry per term, single file (§2), MADR-lite front matter borrowed from research/12’s proposed decision-record convention so both object types share one vocabulary:

## ORDERS_FREEZE
**Status:** active
**Scope:** orders service only
**Confidence:** high
**Source:** decisions/0015-vis-ownership.md, Question #<canonicalTaskId>
**Last confirmed:** 2026-07-18
**Expiry:** 2026-10-16

Orders-service code has had no active owner or planned changes since 2017.
Treat any "who owns this" question as answered by this entry, not as
grounds to re-ask, unless the entry has expired.

**Superseded by:** (empty unless revised; see §4 undo model)

3.5 Write-back diff/PR format

One PR (or direct commit, if Robert’s own lane doesn’t require review gating for his own merges — TBD in 10-architecture.md) per closed Answer, touching exactly the file(s) that Answer produced:

PR title: atlas: write-back for Q#<canonicalTaskId>: <one-line decision summary>

Files changed:
  docs/atlas/GLOSSARY.md          (+1 entry: ORDERS_FREEZE)
  docs/atlas/decisions/0015-vis-ownership.md   (new file)

Provenance footer (in the decision file, per research/12's MADR convention):
  Decided-by: Tomas Zaruba, 2026-07-18
  Drafted-by: <cheap agent/model that generated this diff>
  Question: #<canonicalTaskId>, N=<attachedCount> asks attached
  Confidence: high
  quotedDataClass: NONE (gate from §3.1 passed)

Reviewer is Robert (or a cheap review agent under his lane), checking fidelity, not correctness — did the diff faithfully render what Tomas actually decided, not “was Tomas right.” Correctness was already adjudicated by the Answer; re-litigating it here would recreate the exact bottleneck this whole loop exists to remove. This is the concrete answer to 01’s own open question #6 (“who reviews machine-written doc diffs, does review become the new bottleneck”) — a lighter-weight, different-purpose gate than Tomas’s, scoped narrowly enough that it shouldn’t become one.

3.6 Error / empty / loading equivalents

No spinners, no blank states in the screen sense — the equivalents are:

  • Corpus miss (grep both corpora, nothing found): this is success, not failure — it is the designed path to filing a Question, not an error state. Week 1’s corpus is entirely misses by construction (§1) — that is expected, not a bug to fix.
  • Dedup uncertainty (a candidate match exists but isn’t confident enough to auto-attach): rendered to Tomas as the canonical task with the candidate shown inline — “this may be the same as Q#, attached provisionally, confirm or split” — never silently forced either way. See §4 for the threshold.
  • Expired answer served with warning: if a search hits a GLOSSARY.md/decision-record entry past its expiry, the rendering is never the bare fact — it is the fact plus "EXPIRED <date>, scope <X> — confirm this is still true before relying on it, file a new Question if unsure". This is the single most load-bearing error state in the whole spec, directly enforcing §1’s trust principle.
  • “Loading” has no analog for a human (files are files), but has a real analog for an asking agent: the corpus itself may not be built yet. A zero-result grep in week 1 is not “the search is broken,” it’s “nobody has answered anything yet” — the capture flow (§3.1) must always succeed regardless of corpus state, so a cold corpus never blocks an agent from at least filing.

4. Interaction design

Dup-attach vs auto-resolve confidence split — the single highest-stakes decision in this spec. R8 §4 converges independently across Jira/Zendesk/Stack Overflow tooling guidance: merges are “effectively irreversible in most systems,” false-positive auto-merges “erase important context,” and even vendor best-practice defaults to human-confirmed merging at similarity thresholds around 0.90. Combined with 01’s own MVP boundary (no embedding/RAG in v1 — exact/near-exact string match only):

Match type v1 behavior
Exact re-ask of an unexpired, unrevised Answer, identical scope Auto-resolve. Signal-resume immediately, citing the canonical Answer, always logged. This is the one case 01 explicitly permits without a human touch.
Near-exact text match to an open (unanswered) CanonicalQuestion Auto-attach, no human step — this only changes which bucket a still-pending question sits in, it never fabricates an answer. Low risk, reversible (a human splitting it later costs nothing an answered-merge would have cost).
Anything fuzzier — different wording, plausible-but-uncertain match, any match against an already-answered CanonicalQuestion Always routes to a human as a candidate, never auto-merged and never auto-resolved. One click to confirm or split. This is the conservative default R8’s evidence argues for, and it is where 01’s “not in MVP: embedding/RAG search” boundary does its real protective work — no similarity score in v1 is trusted enough to skip the human on an answered question, only on exact re-asks of one.

Human approval steps: every Answer is Tomas-authored — 01’s own MVP boundary already forbids LLM-generated answers without a human decision anywhere in the chain, and nothing here proposes relaxing that. The only other approval gate is the write-back fidelity check (§3.5), which is Robert’s, not Tomas’s, and checks a different thing.

Undo — answer revision and re-fan-out: per research/12’s supersede-never-edit convention (already the proposed program-wide ADR discipline, R2 §d), a revised Answer creates a new Answer record; the old one’s GLOSSARY.md/decision-record entry gets Status: superseded, Superseded by: <new file>, and its expiry is marked terminated-early. Re-fan-out is necessarily a pull model, stated honestly, not a push this product cannot deliver: any still-open attached Question gets its workflow re-signaled with the corrected Answer (the substrate supports this — R1 §1’s signal-resume mechanism); any agent session that already consumed the old Answer and finished its work has no channel to be reached retroactively — there is no push-to-agent infrastructure anywhere in the substrate (R1 §3 confirms no group broadcast, no agent-facing notification channel exists). Flagged plainly, not smoothed over: a revision fixes the corpus for the next asker; it does not and cannot un-teach an agent that already left with the old answer. This is a real limitation of the design, not a bug to route around.

Rate-limit behavior when Tomas is saturated: the dedup layer already does the only rate-limiting that’s in scope for v1 — N raw asks collapse to 1 queue item regardless of volume, which is the actual point of the whole exercise. Beyond that, 01’s own MVP boundary explicitly excludes SLA tracking, reminders, and escalation (matching R1 §1’s confirmation that none of that exists in the tasks service either), so v1 has no invented backpressure mechanism — queue depth is simply visible (via the existing assigneeGroupSlug filter, R1 §1) to whoever is watching it, which may or may not be fleet monitor’s Queue (§0 point 3, genuinely open). Building an SLA/escalation layer before the naive version has even run for a week would repeat exactly the “shipped clever, not useful” failure plan 001’s own pre-mortem already named.

Notifications: none, by design — matches plan 004’s “near-zero” policy and the same underlying logic (Google SRE actionability doctrine, cited there): Tomas already has a task queue he checks; a second alert channel competing with it is the alarm-fatigue risk, not a mitigation for it.

5. Visual direction

One paragraph, per the brief — everything else is markdown convention, not visual design. There is no palette, no typography system, no component library to specify, because there is no rendered UI surface Atlas itself owns: the answer form’s visual shell belongs to whatever renders Zaruba’s tasks (§3.2’s open question), the digest’s visual shell belongs to fleet monitor (§3.3), and the glossary/decision files are read as plain markdown by both humans (rare) and agents (the actual audience) in whatever tool opens them. The one convention worth stating: markdown headings and front-matter fields follow the exact templates in §3.4/§3.5 verbatim, every time, because consistency of structure is what lets a grep or a future indexer parse them reliably — that is the entire visual design budget this product needs, and Rams’ “as little as possible” is satisfied by there being nothing left to design. N/A beyond that — reason: no owned rendering surface exists to give visual direction to.

6. Prototype recommendation

Fake the dedup, run the rest live. Wizard-of-oz: for one week, Robert manually reads every incoming agent-questions task (already a working query, R1 §1 — zero build) and manually decides merge/no-merge by eyeballing text, recording each judgment (question pair, his decision, and — computed after the fact, not live — a plain string-similarity score for later calibration). Everything else in the loop runs for real: real INFORMATION_REQUEST tasks, real Tomas answers via the real (or fallback, §3.2) form, real write-back diffs into docs/atlas/, real digest rows.

Why fake specifically the matcher and nothing else: the matcher is the one component with zero working precedent anywhere (R3’s bottom line: no product or paper found implements content-based merging of duplicate questions across concurrent agent instances — this is a genuine, unfilled gap, not a “go install X” situation). Everything else in the loop is either an existing Zaruba endpoint (R1) or a markdown file (§2-3) — those don’t need faking, they need running.

Evidence that justifies building the real matcher, stated as thresholds, not vibes:

  1. Volume. Fewer than roughly 5 true-duplicate pairs surface in the week → the matcher isn’t worth automating; Robert’s manual read stays cheaper than building and maintaining a similarity pipeline. (Mirrors 01’s own kill criterion for the whole concept, applied narrowly here to the matcher alone.)
  2. Calibration data. At least ~30-50 Robert-judged pairs, spanning both true and false duplicates, before trusting any automated threshold — R8’s evidence that false-positive auto-merges are hard to reverse means the threshold needs real judged examples behind it, not a guessed cutoff.
  3. Robert’s own time cost becoming the new bottleneck. If manual triage starts measurably eating into the hours the whole program exists to free up, that is itself the signal to automate — ironic, and worth watching for explicitly rather than let it happen unnoticed.

What stays explicitly fake and named as such, so nobody mistakes it for shipped: the matcher’s confidence score (post-hoc, computed for calibration, not live-gating anything during the trial week); any similarity threshold number (there is no threshold yet — that’s the output of this trial, not an input to it).

7. UX risks, ranked

  1. Over-structured capture form — but not for the reason a human-facing form fails. A five-field mandatory schema would tank completion rates for humans (friction, impatience, abandonment). Agents don’t abandon forms — they don’t feel impatience and the “reward” (getting unblocked) is real and immediate, so the actual risk isn’t fewer questions filed, it’s schema-compliant garbage: an agent rubber-stamping "searched": ["N/A"] to satisfy validation without having actually searched. This is a materially different failure mode than the brief’s framing might suggest, and needs a different mitigation than “make the form friendlier” — mitigate by making the field descriptions in the tool/skill spec concrete and specific (not “what did you search,” but “paste the exact grep/search calls you ran”), and by periodic spot-audits of filed questions for hollow answers, not by adding UI friction that only matters for humans.
  2. Stale answer trust collapse (highest-severity, matches plan 004’s own top risk pattern). One expired answer served as current, once, and every future search result is suspect — R8’s “you stop trusting all docs” citation is not a soft warning, it’s the mechanism. Mitigation is entirely §3.6’s expired-with-warning rendering; there is no clever design trick that substitutes for it always firing correctly.
  3. Digest becoming noise — but the noise budget is now shared, not owned. Because Atlas feeds fleet monitor’s digest rather than sending its own (§0 point 2), an unbounded Atlas contribution degrades a product Atlas doesn’t own. Mitigation: the hard cap in §3.3, and a standing rule that any fifth-plus item is a link, never inline text.
  4. Dedup false-positive corrupting N agents at once. The conservative table in §4 is the whole mitigation; there is no UI affordance that fixes a wrong auto-attach after the fact except manual split, which is why the table keeps auto-resolve (as opposed to auto-attach) to the single narrowest case.
  5. Two-plane corpus split friction, lowest-ranked, accepted cost not a defect. Glossary/decisions living outside _documentation/ (§0 point 1) means agents run two search motions instead of one, and the corpus is invisible to Zaruba’s own docs tool until an additional ask (numbered from 2 under the corrected baseline) is negotiated. Ranked lowest because it’s a known, bounded, and reversible cost (a future ask can fix it), not an open question about whether the product works at all.