jschoubben
c0ae8dec96
Found by a full scan before making the repository public, which is the moment the public rule stops being aspirational. A module name identified a specific laptop model — hardware inventory, which is operational detail about one installation rather than a lesson that travels. Generalised. ADR 0028 named a forge username in a repository path, which the public rule forbids, and the sentence had also gone stale: the repository it described was subsequently verified empty of anything unique and removed. Rewritten to state what happened without the username. Removing a disclosure from a record is the same class as fixing a path — the rule that permits it outranks the one that forbids editing. Issue 006 gains its proposed direction: Nox works from within this repository rather than these documents being synced into the knowledge base. Better on three counts — no copy, so no drift; no fourth knowledge system, which was the original objection; always current. But it changes the promise, and the issue says so. ADR 0019 promised these documents would surface BESIDE everything else in a symptom search. An agent that must be asked is reachable, not surfacing, and the two differ in precisely the case the operational memory exists for — someone debugging an error with no reason to suspect HQ knows anything about it. The question narrows to whether a symptom search finds this content without the searcher already suspecting it.
91 lines
4.3 KiB
Markdown
91 lines
4.3 KiB
Markdown
---
|
|
status: open
|
|
opened: 2026-08-23
|
|
located-in: [hal, hq]
|
|
fixed-by:
|
|
amended-design:
|
|
---
|
|
|
|
# 006 — This repository is not indexed into the knowledge base, and the claim that it is holds up a decision
|
|
|
|
## Symptom
|
|
|
|
[`README.md`](../../README.md) states, as the answer to the objection against creating this
|
|
repository:
|
|
|
|
> These documents are still indexed into the knowledge base, so `recall_search` returns them
|
|
> beside everything else. One source, many surfaces — which was always the actual requirement.
|
|
|
|
Searching the knowledge base for this repository's content returns nothing.
|
|
|
|
## Evidence
|
|
|
|
Verified 2026-08-23, two searches against the mesh's operational memory:
|
|
|
|
| Query | Result |
|
|
|---|---|
|
|
| The full title of a decision record in this repository | No results |
|
|
| A distinctive phrase from the decision ledger | No results |
|
|
|
|
No entry, no partial match, no stale copy. The indexing does not exist and appears never to
|
|
have existed.
|
|
|
|
## Why this is an issue and not a task
|
|
|
|
The claim is **load-bearing**. Decision 27 separates HQ into its own repository, and the
|
|
objection it answers was that a fourth knowledge system repeats the mistake the mesh's
|
|
knowledge consolidation was created to fix. The recorded answer is *"indexing, not location"* —
|
|
that the split is safe **because** these documents remain searchable alongside everything else.
|
|
|
|
Without the indexing, the objection stands unanswered and this repository is precisely the
|
|
fourth knowledge system it was argued not to be. Either the indexing is built, or decision 27's
|
|
reasoning is amended to something that is true.
|
|
|
|
It is also, exactly, the failure this repository names in its own rules: a document stating a
|
|
rule about the mesh must say how the rule is checked. This one stated a mechanism and nobody
|
|
checked it — including in the same commit that wrote the rule.
|
|
|
|
## Open questions
|
|
|
|
- Where would the indexing run? The operational memory is written through a mesh capability;
|
|
is this a periodic sync of a repository into it, or a search surface that reads the
|
|
repository directly?
|
|
- Which store — the flat symptom-indexed memory, the structured archive, or both? They have
|
|
different lifecycles ([`03-DESIGN/00-as-is/07-knowledge.md`](../../03-DESIGN/00-as-is/07-knowledge.md)),
|
|
and this content is governed rather than incidental.
|
|
- Public repository, private mesh: the sync direction must not become a path for mesh-specific
|
|
content to arrive **into** these documents.
|
|
|
|
## Proposed direction — Nox is the search
|
|
|
|
*Added 2026-08-23.* Rather than syncing these documents into the knowledge base, **Nox
|
|
([ADR 0027](../../02-DECISIONS/0027-the-product-is-novox-mesh.md)) works from within this
|
|
repository and holds its knowledge directly.** Retrieval becomes an agent reading the source,
|
|
not a copy living in a second store.
|
|
|
|
This is a better answer than the one the README originally promised, on three counts:
|
|
|
|
- **No sync, so no drift.** The failure mode of a derived copy — the enforced copy winning
|
|
while the reasoned one quietly stops being true — cannot occur when there is no copy.
|
|
- **It dissolves the original objection properly.** The argument against a separate repository
|
|
was that it adds a fourth knowledge *system*. An agent with read access adds no store at all.
|
|
- **It is always current**, including for uncommitted work in progress.
|
|
|
|
**But it changes the promise, and that is worth stating rather than glossing.** ADR 0019's
|
|
answer was that these documents would be returned *beside everything else* in a symptom search.
|
|
An agent that must be **asked** is reachable; it is not surfacing. The two differ in exactly
|
|
the case the operational memory is designed for: someone debugging an error who has no reason
|
|
to think HQ knows anything about it.
|
|
|
|
So the open question narrows to one thing:
|
|
|
|
> When a symptom is searched and the answer happens to live in a design document or a decision
|
|
> record here, does the searcher find it without already suspecting it exists?
|
|
|
|
If Nox is the only path, the answer is no, and the reasoning in ADR 0019 needs amending rather
|
|
than satisfying. If Nox also contributes what it knows to a symptom search — or the search
|
|
consults Nox — the answer is yes and the original promise holds.
|
|
|
|
That is a design question for Nox, not a defect in this repository, and it should be settled
|
|
before ADR 0019 is treated as answered.
|