Work, in the open

The second P0 "Now" move of the visibility floor (DEC-0073): the cheap, build-once table-stakes that are currently ABSENT on every surface (verified audit — OG/Twitter cards absent everywhere, canonical absent on all SvelteKit routes, robots/sitemap/JSON-LD absent). Build ONE atomic <SiteHead> component (OG + Twitter cards + canonical + Organization/SoftwareApplication JSON-LD) fed from the landing brand.meta* SSOT, applied across /, /board, /graph; push the same OG + JSON-LD into the docs Head.astro override; add a checked-in robots.txt + an app sitemap at the apex (packages/app/static/) with an AI-crawler allow-list; run `pnpm add @astrojs/sitemap` in @dossier/docs (GROUND-TRUTH CORRECTION: it is NOT currently a declared dep — the audit's "already in the lockfile" was a transitive ghost; package.json declares Starlight/Vercel/design/okf/okf-view/fonts/astro only) and wire it for /knowledge/*; ship one brand-true OG image. SSOT discipline: hygiene metadata is fed from existing SSOTs (brand.meta* / Starlight frontmatter), NOT hand-authored per page; sitemap is a DERIVED view. Analytics stays Vercel-only (DEC-0027) — no third-party trackers.

The go/no-go gate that MUST run BEFORE any code-ingestion substrate infrastructure is built (DEC-0040). The "why"-mining value thesis is testable INDEPENDENTLY of the tree-sitter substrate, so this de-risks the entire bet cheaply on existing machinery (the @dossier/extraction pipeline + the DEC-0009 LLM-as-judge faithfulness judge). Mine git-history rationale (git log -L → filter trivial commits → linked PRs/issues → LLM-explained rationale → OKF decision atoms, confidence: inferred, provenance = commit/PR SHA) from TWO repos and report TWO numbers: (a) decision-RECALL vs. this repo's ~38 hand-authored gold `decision` records (D:\github\dossier as a built-in gold eval set), and (b) faithfulness-PASS-RATE (through the existing judge) + raw decision-YIELD on ONE messy real client repo. That number IS the value thesis. A NO-GO (numbers below the bar) is an equally valid, recordable outcome — the spike de-risks both directions.

A "Next" move of the visibility floor (DEC-0073): once the product-docs register exists (task-stand-up-product-docs-register), wire the comprehension funnel so a first-time visitor on / (and the docs home) has a clear primary path INTO the on-ramp — the "Run your first loop in 15 minutes" tutorial + the plugin install how-to — rather than bouncing off an ADR log or an unexplained landing. Activation over awareness: the CTA points at the asset that converts (the runnable loop / the plugin), feeding the existing privacy-friendly demand signal (DEC-0027 Vercel analytics + the Buttondown early-access list, DEC-0022). No new trackers. Depends on the product-docs register landing first.

Guarantee that `/knowledge/` resolves to a 200 with a faithful overview for ANY served client KB, including one with no root `index.md` — the DEFAULT output of the ingest→extract pipeline (and the client-new / generate-landing flows). DEC-0058 found that when no root `index.md` exists, `@dossier/okf-view` `routes.ts` `hasRootIndex()` returns false ⇒ `generateSidebar()` omits the Overview link AND no `/knowledge/` page is generated ⇒ `GET /knowledge/` is a 404, while the shared `SiteHeader`/`SiteFooter` hardcode the Docs link to `/knowledge/`. DEC-0058 records the INVARIANT and the SEAM but deliberately does NOT pick the implementation, framing two candidates for the owner to decide.

Build Layer-2 of the DEC-0059 untrusted-by-default boundary: an ingestion-boundary detect-and-drop ensemble that runs BEFORE persistence/embedding/extraction. Combine Presidio (RECALL-tuned, β=2 — a missed PII false-negative that lands is worse than over-dropping) + custom Presidio recognizers encoding the client's "P2"-tier patterns (ad-hoc recognizers / EDM-style custom SITs) + a cloud DLP (e.g. Google SDP) as a second probabilistic opinion. CRITICAL: vanilla Presidio is ~0.35-0.38 F1; configuration boosts F-score ~30% — so do NOT deploy unconfigured, and do NOT trust the detector — MEASURE it with a validation harness (Microsoft presidio-research evaluates at system/NER/recognizer level) and report a measured F2/recall number against a labelled corpus before it is "good enough". This is a LAYER, never the guarantee (every detector has irreducible false negatives — the architecture, not this detector, carries the guarantee — see DEC-0059). Gate happens at the chokepoint before embed/index/extract, because the GraphRAG vector index is in-scope sensitive data (embeddings do not anonymize PII). Optionally front it via LiteLLM standalone apply_guardrail (runs Presidio with NO LLM call) OR call Presidio directly (LiteLLM is a thin client over Presidio); if LiteLLM is used pin the Docker image (PyPI litellm 1.82.7/1.82.8 were compromised) — but compliance must NOT depend on LiteLLM. Detail + citations: research/2026-06-18-sensitive-data-and-injection-defense.md §5, §10.

DEC-0059's blast-radius-containment leg at the runtime substrate: a siloed git repo contains the DATA but NOT the INJECTION — containment depends on the runtime substrate, so make the tenant a PROCESS / NETWORK / KEY boundary, not just a directory. Four leak channels and the control that guarantees isolation on each (from the research): (1) VECTOR INDEX — poisoned embedding retrievable cross-tenant if pooled by a client-supplied filter → per-tenant namespace/index + inject the tenant filter SERVER-SIDE from a SIGNED claim (never client-supplied); (2) MCP SERVER PROCESS — in-flight data / session-hijack across tenants → ONE server instance per tenant (own process + network namespace), session bound server-side to <tenant_id>:<session_id>, never authenticate by session alone, token passthrough FORBIDDEN (use RFC 8693 token exchange, per-tenant scoped creds, minimal scopes); (3) EXTRACTION-AGENT CONTEXT — injection in tenant A's content steers tenant B's run → one tenant per run, fresh context, no shared memory (subagents share the parent process/sandbox, so a fresh process per tenant); (4) MODEL/PROMPT CACHE — UNVERIFIED in docs, treat low-likelihood → per-tenant cache scope until confirmed. Per-tenant key enables crypto-shred on offboarding (the vector index is in-scope PII, DEC-0059 (a)). This INTERSECTS DEC-0053 (one-server-one-tenant fleet topology) and DEC-0054 topology and EXTENDS DEC-0011 (one-server-one-tenant at the file boundary) down to the runtime/process/index level, and builds on DEC-0020 (git-per-tenant). Detail + citations: research/2026-06-18-sensitive-data-and-injection-defense.md §9f (multi-tenant blast-radius table), §2.

The single most important file-path takeaway of the DEC-0059 synthesis: Unstructured fails OPEN/EMPTY, not closed. Encrypted / copy-protected files return ZERO elements with only a logged warning — a silent empty result reads downstream as "clean", so a regulated document Dossier could not parse would sail through as if it had no sensitive content. Dossier MUST add its OWN fail-closed quarantine wrapper around the Unstructured connector that treats zero-element / encrypted-by-header / unknown-MIME files as QUARANTINE-BY-DEFAULT (deny, route to human review, never pass through as clean). Also note: Unstructured's default scan is text-only and misses PII in images/scanned PDFs (Presidio Image Redactor + OCR is beta) — so an unreadable/zero-element file is exactly the case that must NOT be trusted. This is the fail-closed leg of DEC-0059's "every detector is probabilistic, so fail closed" principle, applied to the file path specifically. Detail + citations: research/2026-06-18-sensitive-data-and-injection-defense.md §7b.

A "Next" GTM move of the visibility floor (DEC-0073): the DEC-0014 Claude Code plugin + marketplace is the highest-leverage UNDERUSED distribution channel — the plugin is built and `claude plugin validate --strict`-clean, but it is NOT yet verified as an installable PRODUCT (a user installing it from the marketplace and running their first loop). Close the gap: verify the end-to-end install path (marketplace → install → first loop), fix whatever blocks it, and make the "Install the Claude Code plugin" how-to (task-stand-up-product-docs-register) match the verified reality. This is the product-led + agency-channel proof motion (DEC-0023/DEC-0052), NOT a pricing page or paid ads.

DEC-0041 removed the ~120 ms per-call node cold-start from PostToolUse capture (dumb-fast .cmd + narrowed matcher + off-hot-path distiller). The PreToolUse board-claim-guard.mjs (DEC-0024 §5, currently opt-in / not wired) is a Node script — wiring it standing as-is would RE-INTRODUCE the exact ~120 ms cold-start DEC-0041 just removed, on every mutating call, on top of capture. Before it goes standing: give it the same dumb-fast treatment (a .cmd/shell front that fast-paths the common no-opinion cases with ~0 interpreter boot, OR fold the claim check into the runtime worker) rather than a per-write node boot. The README already flags this; this task makes the follow-up durable and owned.

During the DEC-0018 brand recalibration, WCAG 2.1 relative-luminance + contrast-ratio arithmetic was written ad hoc to /tmp at least four-to-five distinct times (clay ramp, on-accent, distinct-hue spread) and re-derived rather than reused — DEC-0041's Review names this verbatim as a surfaced improvement. There is no canonical contrast checker in the repo today (confirmed: no scripts/check-contrast.mjs). Extract a small, dependency-free, checked-in utility that takes the @dossier/design token tree (or explicit fg/bg pairs) and reports contrast ratios against the AA floor DEC-0018 adopted, so the next palette change is validated by `node scripts/check-contrast.mjs` (ideally also surfaced as a drift-style test like css.test.ts) instead of throwaway /tmp scripts. This makes the WCAG floor a repeatable, auditable gate rather than tacit arithmetic.

CONTINGENT on the code-ingestion v1 build proceeding (DEC-0040), and DOWNSTREAM of the de-risk "why" spike (task-codebase-why-mining-spike): author per-language tree-sitter tag-query (.scm) + schema-data packs for languages beyond the v1 TS/Python cut (Go, Java/C#, etc.). A language pack is the UNIT OF INCREMENTAL LANGUAGE COVERAGE — substrate-internal DATA that emits into the CLOSED structural edge kinds (contains/imports/calls/references), NOT a fork of the universal substrate. Prioritize by DXA-client stack clustering (which client codebases actually show up). Each pack is INDEPENDENTLY shippable. BLOCKED-ON / downstream of the spike: do not start until the spike returns a GO and substrate v1 exists to emit into.

After DEC-0048 (dev-aware docs-origin linking, no dev proxy), the app links into the @dossier/docs reading surface (/knowledge/* + the KB atom routes) via its OWN dev origin (default http://localhost:4321), because two Vite-based dev servers cannot share one origin (the rejected dev proxy). Consequence: the docs links only resolve in dev if the docs dev server is ALSO running. Today this is implicit — root `pnpm dev` is `pnpm -r --parallel dev`, which does start both, but nothing tells a contributor that the app alone is insufficient, or that they can run just the docs with `pnpm --filter @dossier/docs dev` (Astro on 4321), or that VITE_DOCS_ORIGIN overrides the port. Make the requirement explicit so a contributor who runs only the app does not hit dead docs links and assume a bug. Document it where a dev will see it: a note on the root `dev` script intent (and/or the @dossier/app package — no packages/app/README.md exists yet) covering: (1) local dev needs both the app AND @dossier/docs (astro on :4321); (2) `pnpm dev` at the root runs both in parallel, OR run `pnpm --filter @dossier/docs dev` alongside the app; (3) the docs origin is configurable via VITE_DOCS_ORIGIN ($lib/docs); (4) if the docs server is down the docs links fail to load against :4321 (expected — the surface is not running — not an app bug). Keep it SSOT: point at $lib/docs / vite.config.ts NOTE rather than re-explaining the two-dev-servers-one-origin rationale (that lives in DEC-0048 + the vite.config.ts comment).

The RBA Firecrawl tenant needed TWO post-hoc curation passes for the same root cause: the extraction EMIT path assigns vertical/concept types weakly. A single-client SOW instance (a named delivery RBA ran for one client) emits as a generic `workflow` instead of the DXA `engagement` type (closed by the one-time curation pass [[task-rba-engagement-retype-client-workflows]] — 6 atoms re-typed `workflow`→`engagement`, tenant commit `975cc83`); and deliverables / process phases emit as `system` instead of `artifact`/`process` (closed by [[task-extraction-system-type-discipline-rba]] — 23 atoms re-typed, tenant commit `8229530`). Both were field-fixed by deterministic data surgery on the RBA tenant, but the surgery is a STOPGAP — the durable lesson (noted, never filed) is that the EMIT path should make these type calls at extraction time. Build an emit-time type-discipline heuristic: e.g. a client-name + single-client-SOW signal → DXA `engagement` (not `workflow`); a deliverable/output signal → `artifact`; a phase/activity signal → `process` (not `system`, which is reserved to actual tools/software/platforms per the knowledge-model). Faithfulness over coverage — when no signal grounds a stronger type, fall back conservatively, never fabricate. Validate against the existing [[0009-extraction-eval-methodology]] judge so a heuristic that over-fires is caught. This closes the loop: future client extractions emit type-disciplined OKF without a manual re-type pass.

In the first live FirecrawlConnector RBA run (DEC-0055), 1 of 203 extract calls failed: segment #82 returned malformed model JSON, so its `ok=false` / `atoms=0` and its atoms were SILENTLY LOST — no retry, no repair, no surfaced error beyond the failure count. Across a 75-page crawl one lost segment is small, but the failure mode is systemic: a single transient/malformed model response drops a whole segment of a client's knowledge with no recovery. Add a bounded retry/repair path in the extraction (or subscription-client) layer: on a parse/validation failure, retry the segment (optionally with a JSON-repair or re-prompt step) before giving up, and surface an unrecoverable segment loudly rather than only as a count. Must preserve DEC-0009 faithfulness discipline (a repaired segment still passes the same validation/judge floor) and the offline-test seam (DEC-0008).

Security hardening of the live Firecrawl web path proven in DEC-0055 (the first live FirecrawlConnector run against rbaconsulting.com), per DEC-0059's untrusted-by-default boundary applied to the web source. Three architectural closures from the research: (1) PIN self-hosted Firecrawl >= 2.0.1 AND block internal/link-local egress at the NETWORK layer — two SSRF CVEs (CVE-2024-56800 fixed 1.1.1; CVE-2025-57818 fixed 2.0.1), and the playwright-service SSRF was deemed UN-patchable in code, so the network-layer blocklist is the real control, not the version pin alone. (2) NEVER inject client session credentials into a public crawl — scrapeOptions.headers can carry cookies/auth; a public crawl must never carry the client's session. (3) Keep safe-by-default scoping ON (allowExternalLinks/allowSubdomains/crawlEntireDomain all default false; limit default 10000) and pair Firecrawl's includePaths/excludePaths (crawl-frontier filters, NOT a security boundary — excludePaths has confirmed silent-fail bugs) with a Dossier-owned pre-ingest allowlist + post-crawl host validation. robots.txt is honored by default but is advisory, NOT a PII control (a public-but-disallowed page still has PII). This is the web-source realization of DEC-0059's containment + untrusted-content principles, directly extending DEC-0055 and DEC-0021 (the wired Firecrawl path). Detail + citations: research/2026-06-18-sensitive-data-and-injection-defense.md §7a.

@dossier/okf-view exposes a SINGLE barrel that re-exports the fs-based route/kb readers (knowledgeDir / getRouteMap / readKbAtoms / generateSidebar) ALONGSIDE the pure client-safe view-model helpers + types. Any client value-import of that barrel therefore drags node:fs into the browser bundle — the exact bug class that broke the DEC-0072 Track-1 hydration (OkfMeta.svelte value-importing conceptBadgeClass pulled node:fs into the client and threw on hydrate; SSR HTML looked fine, only a real browser exposed it). In Vite dev there is no tree-shaking so it ALWAYS leaks; prod tree-shaking removes it but is fragile (one stray value-import re-introduces it). Fix: expose a client-safe subpath/entry (view-model + types only) DISTINCT from a server-only entry (the fs readers), so client code can only reach the safe surface; and add an ESLint/CI guard that fails on value-importing the fs readers (or node:fs) into client code. Note: @dossier/okf-view is a shared LEAF consumed by BOTH @dossier/app and @dossier/docs — the split must keep both consumers green.

DEC-0046 added an accessible mobile-disclosure hamburger to the shared SiteHeader, whose two→X glyph is drawn with HARD-CODED geometry — `height: 2px` on the bars and `±6px` vertical offsets (packages/app/src/lib/components/SiteHeader.svelte, .site-menu-toggle__glyph rules). Every other value in that component is an existing --ds-* token (spacing/color/radius/motion/shadow/z-index/weight/text), so the bare 2px / 6px are the only token-discipline bypass left after DEC-0046. @dossier/design has NO --ds-border-width-* or --ds-icon-* token family today (confirmed: grep of packages/design finds neither). Add a small icon/stroke-geometry token family to @dossier/design (e.g. --ds-border-width-thin / --ds-icon-stroke, and an icon-glyph size if warranted), regenerate styles/dossier.css via renderCss() (the ONLY tokens→CSS path, drift-tested per DEC-0010), and replace the hard-coded 2px (and the derived offsets, ideally calc()-expressed off the token) in SiteHeader. The FDE flagged this as deliberately OUT OF SCOPE for the DEC-0046 polish pass — the component ships correct today; this closes the token-discipline gap so the glyph geometry is tunable + auditable like everything else.

DEC-0059's Layer-3 compensating control: because detection has irreducible false negatives, the boundary must keep a tamper-evident audit trail that PROVES nothing sensitive landed — but the trail must record DECISIONS (per-item verdict + sensitivity-label snapshot + drop reason), NEVER the sensitive payload, or the audit log itself becomes the breach. This is the "audit paradox". The discipline: scrub BEFORE anything reaches a logged layer, so a logging regression physically CANNOT capture raw PII. Same payload-free principle DEC-0041 applied to the trace tier (capture the decision/metadata, not the sensitive content), now applied to the sensitive-data drop log. Tamper-evidence (append-only / hash-chained) so the proof-of-non-landing is trustworthy. Watch the known LiteLLM nuance: if LiteLLM is in the model path, turn_off_message_logging — but it has a documented history of leaking messages into the Postgres proxy_server_request field anyway, which is exactly why scrubbing must happen at ingestion before any logged layer. Detail + citations: research/2026-06-18-sensitive-data-and-injection-defense.md §6, §10.

DEC-0047 made the dev-only client landing preview (/preview/<slug>) render the CLIENT's REAL OKF knowledge graph inline beneath the landing — over a SHARED buildGraphView + GraphExplorer, reading the client's served OKF directly via the new readKbAtoms(dir) param, WITHOUT perturbing the process-wide DOSSIER_KB or the prerendered /graph. The /board half is still un-tailored: the preview's "live surfaces" showcase card for /board links to Dossier's OWN board in the monorepo dev server (DOSSIER_KB unset → /board reads knowledgeDir() = Dossier's own task atoms), contradicting the tailored page's "both surfaces read YOUR OKF" claim — the same gap DEC-0047 just closed for the graph, still open for the board. This task is the board sibling: extract the board's payload recipe into a shared board view-model (the analog of buildGraphView) and render the client's OWN task atoms inline beneath the landing via readKbAtoms(clientDir).filter(type === 'task'), in the SAME dev-only preview wrapper, leaving the shared LandingPage template untouched (DEC-0037 invariant #1). Same invariants as DEC-0047: READ-ONLY + KB-agnostic (read the client dir directly, never mutate DOSSIER_KB; the prerendered /board stays untouched); host route map → null deep-links for client ids with no reading surface (honest, never a crash); crash-safe empty state on a missing/empty dir; DEV-ONLY by construction (the preview route 404s in prod and the registry imports only inside the import.meta.env.DEV gate, so no client copy ships). NOTE: the board's current onMount interactivity is being Svelte-ified separately (task-svelteify-board-interactions); coordinate so the shared view-model lands cleanly against whichever board shape is current, but this task is the inline-on-preview rendering, NOT the JS rewrite.

The 2026-06-17 landing length/rhythm pass ([[0037-landing-as-tailorable-template]], second polish round) merged the labelled 5-stage loop diagram UP into the hero and deleted the standalone "how it works" section, replacing the abstract `HeroLoop` animation with the labelled diagram driven by the hero's existing IntersectionObserver. That removed `HeroLoop.svelte`'s ONLY import from `LandingPage.svelte`, so `packages/app/src/lib/components/HeroLoop.svelte` (~12.4KB, the high-craft animated learning-loop signature, ported pixel-faithfully from HeroLoop.astro in DEC-0043 Phase 4) is now DEAD CODE — present but unreferenced. It was deliberately NOT deleted in the polish turn because (a) it is high-craft and (b) four `src/styles/landing.css` comments (lines 503, 769, 976, 993) cite it as the canonical motion-convention reference ("Matches HeroLoop's conventions exactly", "GATING (mirrors HeroLoop)", "Same inline-index convention HeroLoop uses", "in the spirit of HeroLoop"). Resolve the dead-code: either DELETE the component and reword those four comment references to stand on their own (the conventions they describe now live in the hero `.loop__diagram` CSS itself), OR formally PARK it (a header note + a single canonical "motion convention reference, not wired" comment) so a future reader knows it is intentionally retained as a pattern source, not an active surface. Confirm grep first: the only live "HeroLoop" textual references are this file, the four landing.css comments, and the `bindHeroLoopObserver` function name in LandingPage.svelte (a function name, not an import of the component) — no other surface imports it.

Layer-1 of the DEC-0059 boundary: honor the client's EXISTING classification at the M365 source, gating egress before bytes leave their environment. Read Purview/MIP sensitivity labels at ingest via Microsoft Graph extractSensitivityLabels (GA; POST /drives/{id}/items/{id}/extractSensitivityLabels — needs only Files.Read.All; returns sensitivityLabelId/assignmentMethod/tenantId); discover the client's label taxonomy via GET /security/dataSecurityAndGovernance/sensitivityLabels + extractLabel/extractContentLabel. Detect labels WITHOUT the MIP SDK where possible: labels persist as clear-text MSIP_Label_{GUID}_* metadata (MSIP_Label_GUID_Enabled = true is the canonical "is-classified" signal) — but this holds ONLY for unencrypted, non-co-authored files; RMS/IRM-encrypted files need the MIP SDK. Use Graph delta query for incremental/resumable sync (deltaLink/nextLink; 7-day token expiry, 410→full resync). Pair with a client-side Purview DLP egress block (a sensitivity label as a CONDITION can ENFORCE block, not just warn). LOAD-BEARING CAVEAT (Microsoft's own words): "DLP's ability to detect sensitivity labels in SharePoint and OneDrive is limited" (pre-enablement labels, DKE/password-protected, >12MB encrypted Office, images, zip contents) — so L1 CANNOT stand alone, it REQUIRES the L2 detector backstop (task-ingestion-detector-ensemble-measured-recall). Detail + citations: research/2026-06-18-sensitive-data-and-injection-defense.md §4.

DEC-0036 gave the log-auditor a durable outlet for surfaced findings — file an OKF `task` on the board + a structured Recorded/Found/Filed/Deferred return — instead of prose that evaporates. The other report-only agents have the same gap. qa-reviewer's spec literally says "reports findings, does not silently fix" with no durable home for those findings; principal-architect drafts decisions but routes ripple-effects as prose. Decide whether (and for which agents) to adopt the same surface-improvements-as-board-tasks pattern + structured return, then have the owning agents' prompts updated. Scope decision first; do not edit the agent files until the scope is set.

DEC-0061 made the going-forward norm — a knowledge/log.md entry is a terse one-liner plus a wiki-link, and the why lives ONLY in the atomic ADR — and added a SOFT warn-only kb:check lint for it. The existing ~233 KB of multi-paragraph log entries (136 over the 320-char one-liner budget at filing time) are a SECOND copy of ADR rationale, an SSOT violation, but were deliberately NOT rewritten in the DEC-0061 pass (a large separate sweep). This task is that optional sweep: collapse each legacy entry to a one-line pointer, moving any rationale that lives only in the log (not in its ADR) into the ADR first so nothing is lost.

DEC-0059's containment applied to the SERVE side (the consumer). Poisoned OKF atoms already in the repo are retrieved as TRUSTED context, so server-trust checks don't help — and stored RAG poisoning persists (PoisonedRAG: ~5 malicious passages → ~90% hijack of a target query; AuthChain: a single poisoned doc suffices for multi-hop). The defense is architectural, not detection: (1) apply the SAME deny-by-default egress + READ-ONLY tool surface at serve time (so an atom saying "POST the user's data to evil.com" structurally cannot act) — the serve-side mirror of task-extraction-deny-by-default-egress-sandbox; (2) PROPAGATE provenance / confidence / trust-tier on every atom to the consuming agent (Dossier ALREADY stamps these — DEC-0001 provenance, the confidence enum) so the consumer down-weights low-trust/externally-sourced content and treats retrieved text as DATA not instructions (Spotlighting/datamarking: probabilistic, raises attacker cost, never a guarantee); (3) add an OUTPUT hook that blocks atom-instructed side effects. Residual (state honestly): this constrains DAMAGE (no exfil, no side effects, blast-radius = one tenant) but does NOT 100% prevent a poisoned atom from biasing a generated ANSWER within that tenant — provenance tags + human curation + verify-kb are the scrub path (verify-kb raises the cost of a poisoned atom landing, it is NOT the containment guarantee). Recursively strip invisible-char smuggling (Unicode tag chars U+E0000-E007F, zero-width) at ingestion too. Detail + citations: research/2026-06-18-sensitive-data-and-injection-defense.md §8, §9a, §9f (serve-layer poisoning).

During the DEC-0018 brand session, packages/design/scripts/build-wordmark.mjs — the generator that outlines the "Dossier" wordmark from the self-hosted Newsreader font into committed brand/wordmark.svg path data — hit an ERR_MODULE_NOT_FOUND mid-session (around its node:url createRequire/fileURLToPath import), and several npm-view probes for font tooling returned E404 (@fontsource-variable/ibm-plex-mono, fonteditor-woff2). The script settled on wawoff2 (resolves at 2.0.1) + opentype.js, the brand work landed (DEC-0018) and the full build/test suite was green — so the committed wordmark.svg is correct and shipping. What is NOT confirmed is that the GENERATOR re-runs cleanly from a fresh checkout. Confirm whether build-wordmark.mjs currently runs end-to-end (node scripts/build-wordmark.mjs from packages/design) on a clean install; if it does not, fix the ESM import and pin the font/woff2 deps so the wordmark stays re-buildable. This is a generator for a committed asset (not on the CI hot path), so priority is p2 — but a silently-broken generator means the wordmark can never be regenerated when the face/shape changes.

Minor hardening surfaced by the first live FirecrawlConnector RBA run (DEC-0055): the harness `clients/rba/harness/subscription-client.mjs` spawns `claude` with `shell:true`, which emits a Node DEP0190 deprecation warning (passing args with shell:true is deprecated). Replace the shell-spawn with a direct `spawn(cmd, args)` (no shell) — which is also safer (no shell-injection / quoting surface) and quieter. NOTE: the harness lives under `clients/` which is gitignored (a local sandbox, not committed to the Dossier repo per DEC-0020), so this is sandbox-harness hygiene rather than shipped-product code — low severity, easy fix.

The /board surface in @dossier/app carries ~270 lines of vanilla JS — filter, sort, the quick-look dialog, and the Refine popover — lifted VERBATIM from the old Astro board.astro into the Svelte page's onMount during the DEC-0043 migration (Phase 3). DEC-0043 explicitly deferred Svelte-ifying this, not dropping it: the migration kept the working JS to land the framework move without also rewriting the interactivity in the same pass (separate-the-changes discipline). This task is the deferred Phase-7 rewrite: replace the imperative onMount DOM-wiring with idiomatic Svelte 5 — reactive $state for the filter/sort criteria, derived task lists, {#each}/{#if} for the rendered groups, a <dialog> bound for quick-look, and the Refine popover as a component — so the board is maintainable Svelte rather than a string of querySelector/addEventListener calls. Behavior must stay byte-identical to what shipped (filter/sort/dialog/popover all proven in-browser at migration time); board.css moves unchanged; the read-only / KB-agnostic / no-mutation invariants (the site only READS task atoms, never git add/commit) are preserved. svelte-check stays 0/0 and the suite stays green.