A snapshot: read at commit 707a04c7ce8 on 2026-10-18T00:06:01Z by majordomus 0.29.0. Nothing on this page is read again. See it live
I0801
Narrow the Clean Extraction Boundary and record what was adopted
Where it stands
devtask.issueMoves
plan.transitionWhat it is
- Objective
- Rewrite the Clean Extraction Boundary in docs/DESIGN.md so that it permits a generic deterministic provenance graph derived from this repository's own artifacts while continuing to exclude everything it excludes today, and record in docs/EXTRACTION_REPORT.md which architectural ideas from the studied prior art were adopted by re-derivation and which were refused, each with its reason.
- Why
- The boundary currently reads 'graph semantics' among the things excluded absolutely. The rest of this milestone builds a reference graph. Shipping that against a published boundary that forbids it would make the boundary decorative, which is precisely the failure mode this project was built to detect. The adoption record exists so that the next reader can tell a re-derived idea from a copied implementation.
- Now
- docs/DESIGN.md lists 'graph semantics' in the absolute exclusion sentence and lists ten items that crossed the boundary by abstraction. docs/EXTRACTION_REPORT.md records the evidence behind the v0.1 decisions and says nothing about session or knowledge tooling.
- Wanted
- The exclusion sentence distinguishes the domain, inference and semantic machinery that stays out from the generic provenance graph over this repository's own files that is now in. The adopted list names the session and knowledge ideas taken by re-derivation. A refusal list names what was studied and deliberately not taken, each with the reason, including the database, the embedding layer, the vault renderer and the copied-narrative session note.
- Done when
- unknown: the record declares no `completion`
- Risk
- A boundary narrowed to fit the feature being built is not a boundary. The wording has to be one a reader could use to refuse a future proposal, not one that merely describes what is about to be committed.
Acceptance
- The boundary states what kind of graph is permitted and what kind is still excluded, in one sentence a reader can apply to a proposed feature
- The adoption list names each adopted idea and the Majordomus object it becomes
- The refusal list names each refused idea and why, with the databases and the embedding layer among them
- No internal path, hostname, component name or quotation from the studied material appears anywhere in either document
- Validation
bin/majordomus doctorbash test/run.sh 08_no_forbidden_constructs- Evidence required
boundary_rewritten- Evidence present
boundary_rewritten
Scope
- Touches
docs/DESIGN.mddocs/EXTRACTION_REPORT.md- Not
Any implementationAny change to the ten items already recorded as having crossed the boundaryNaming any internal path, component or vocabulary of the studied material- Depends on
- none
- Priority
- p1
- Profile
- deep-work
- Parallel safe
- true
- Owner
- unknown: the record declares no `owner`
The work so far
- Branches
- none
- Merged
- none
- Commits
0- Trunk
- master
- Sessions
- none
- Created
- 2026-09-04
- Updated
- 2026-09-04T15:40:54Z
- Started
- 2026-09-04T15:37:53Z
- Verified
- unknown: the record declares no `verified_at`
- Completed
- 2026-09-04T15:40:54Z
Synchronisation
- Adapter
scripts/github-sync- Repository
- unknown: the derived plan's header carries no repository
- External issue
- unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
- State there
- unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
Findings
Nothing is wrong with these records.