ADR-013 — Knowledge source of truth: the monorepo, not a central palace

:::note Contenido en inglés Esta página del wiki se sincroniza desde la base de conocimiento en inglés y todavía no está traducida. :::

canonical · tech-lead · updated 2026-06-28 · source

• Status: Accepted
• Date: 2026-06-28
• Owner: Tech Lead
• Related issue: #909 (effort), #910 (this ADR — the decision gate)

Context

• Two sources of truth contradicted each other. The monorepo knowledge/ has been the authoritative knowledge base since effort #884 (the LLM-Wiki pattern, the self-writing wiki, knowledge-lint, the graph). A separate private repo tuempresadigital/knowledge ("knowledge palace") modelled the inverse — a "shared-first SoT" with a read-only kb lens (bin/kb), intended to be mined by MemPalace and lensed by tedos-builder. knowledge/llm-wiki-pattern.md recorded the open conflict; José deferred the direction.
• The facts on the ground resolve it. Audited 2026-06-28: the palace tedos/ wing holds 1 doc; its _shared/ holds 10 docs of which 9 are stale duplicates already in the monorepo (brand, brand-tone, design-principles, design-source-of-truth, orientation, product-development-flow, icon-style, avatar-style, grid-system — the monorepo copies are fresher). Only operating-manual.md is palace-unique. So "reconciliation" is a merge the monorepo already wins, not an import.
• The _shared/ content was mostly tedos's own brand/design/process mislabelled as "shared" — a different client (e.g. nts) would never use tedos's brand. The genuinely cross-project material (conventions, the orientation pattern, the dev flow) already ships to every repo through the claude-kit plugin (/kit-update). There is no real need for a central knowledge repo or a lens.
• José (2026-06-28): monorepo is SoT; for cross-project knowledge, "0 infra nueva" — use the existing plugin channel, do not stand up a _shared package or keep the central repo.

Decision

The monorepo knowledge/ is the single source of truth. Knowledge is per-project and self-owned; cross-project conventions distribute through the claude-kit plugin. The central palace repo and its kb lens are retired.

• Per-project SoT (fractal). Each project's monorepo owns its own knowledge/ and is its own SoT (tedos owns tedos's, nts owns nts's). No repo points at another repo's knowledge/.
• Cross-project sharing = the plugin, not a repo. Genuinely reusable conventions live as templates/rules in packages/claude-kit-plugin and reach every repo via /kit-update. No new infrastructure — no _shared package, no central knowledge repo, no lens.
• Retire the lens. bin/kb + taxonomy.yaml in the palace are removed. The lens's read function is already covered three ways: humans read docs.tuempresa.digital (the docs site already publishes knowledge/ via sync-knowledge.mjs); semantic recall is MemPalace (mining the monorepo knowledge/); machine-readable conventions are the plugin.
• Retire the palace repo. tuempresadigital/knowledge is archived/renamed after salvaging its two unique docs into the monorepo.

Scope boundary. This decides where knowledge lives and how it is shared. It does not change the LLM-Wiki pattern, knowledge-lint, or the graph (all monorepo-side, unchanged). It does not introduce a runtime dependency between client apps.

Consequences

Positive

• One SoT, no drift between palace and monorepo. The thing that was contradictory is gone.
• Zero new infrastructure — the cross-project channel (plugin) and the read surfaces (docs site, MemPalace) already exist and already reach every repo.
• No bad coupling: no repo depends on the tedos monorepo for its knowledge.

Negative / trade-offs

• Truly-shared knowledge now round-trips through a plugin release (/kit-update) rather than a live central read. Acceptable: shared conventions change slowly and are already distributed this way.
• The palace's git history for the salvaged docs is left behind (the monorepo copies are the live ones); we salvage content, not history, for the 1–2 unique files.

Follow-ups required

1. Salvage the 2 palace-unique docs. Done — nothing to import. Audited both: the palace's only non-duplicate docs are _shared/operating-manual.md (asserts the now-retired "edit in the palace = SoT" model and otherwise duplicates monorepo brand/design/process docs) and tedos/planning/cloud-chat-multitenant.md (a superseded plan — the multi-tenant cloud chat shipped as apps/chat; the live doc is wiki/apps-chat.md). Importing either verbatim would re-introduce stale/contradictory content, so neither is salvaged.
2. Done — knowledge/llm-wiki-pattern.md § "Relationship to the central knowledge palace" updated from "UNRESOLVED — deferred" to point at this ADR.
3. Repoint consumers when convenient: MemPalace mining + tedos-builder lensing → monorepo knowledge/ (both already effectively read the monorepo; no central source remains to mine).
4. Promote any genuinely cross-project convention into packages/claude-kit-plugin/templates|rules as it arises — no backlog identified (the palace _shared/ was tedos-specific, already in-monorepo).
5. (José — the only remaining action) Archive/rename the external repo tuempresadigital/knowledge (e.g. → knowledge-archive) and drop bin/kb. Outward-facing/irreversible, so the owner executes it.

Alternatives considered

Option	Why not
Palace-central as SoT (edit-there, lens-here)	Inverts #884; the palace wing is near-empty while the monorepo holds the live content — it would be a large backwards migration of the real corpus.
Hybrid: _shared package for cross-project, monorepo for project content	Two SoT with a boundary to police; new infra to maintain. José: "0 infra nueva." The plugin already is the cross-project channel.
Keep both, document the boundary	The status quo — it is exactly the contradiction this ADR exists to end.

References

• Effort #909 (reconciliation), #910 (this ADR); effort #884 (monorepo knowledge/ made authoritative).
• knowledge/llm-wiki-pattern.md § "Relationship to the central knowledge palace" (records the prior conflict).
• knowledge/sources/kit-resource-inventory.md, knowledge/sources/skill-catalog-audit.md (the plugin/catalog distribution model).
• External repo audited: tuempresadigital/knowledge (_shared/ 10 docs, tedos/ 1 doc, bin/kb, taxonomy.yaml).
• decisions/log.md.