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

I0808

Extract nodes with identities that survive a rebuild

Where it stands

devtask.issue

Readiness: complete completion is recorded and every required evidence token is present
Status: DONE
Can start: not now
Milestone: M003
Milestone status: ACTIVE
Wave: 2
Waiting on: none
Holds back: I0809
Behind it in all: 8
Evidence: 2 of 2

Moves

plan.transition

What it is

Objective: Implement the extract and normalise stages in lib/knowledge.awk: one node per canonical object, with an identity derived from its canonical id or its repository path, a kind that is only asserted when a structural fact establishes it, and a title taken from the record or from the document's first heading.
Why: Identity is what makes the index a pointer rather than a copy. An id derived from enumeration order or from a title changes when something unrelated changes, and every reference to it silently becomes wrong. Classification that guesses from prose is the same failure in another dimension: a confident wrong kind is worse than an honest unknown.
Now: The canonical objects already have identities — claims, milestones, issues, profiles, prompts and doctrines are all keyed — and lib/project.awk is the precedent for deriving a model in awk from flattened records.
Wanted: Nodes are emitted in a stable order with ids of the form kind and canonical key, where the key is the object's own id for structured records and its repository path for documents. A kind is asserted from the source class or from an explicit field, never from a keyword found in prose, and an unrecognised source yields the unknown kind rather than a guess.
Done when: unknown: the record declares no `completion`
Risk: Deriving a document id from its path means a rename is a delete and an add, which is correct and will look like churn. The alternative, a content hash identity, makes an edit a delete and an add, which is worse.

Acceptance

Two syncs of an unchanged repository produce byte-identical node output
Renaming a document changes that document's node id and no other
A node's kind comes from its source class or an explicit field, and a case proves prose containing a kind word does not change it
An unrecognisable source produces a node of kind unknown rather than being dropped or guessed at
Extraction from a generic Markdown document takes only the path, the first heading and explicit links

Validation: bash test/run.sh 73_knowledge_nodes
Evidence required: node_identity_stableunknown_stays_unknown
Evidence present: node_identity_stableunknown_stays_unknown

Scope

Touches: lib/knowledge.shlib/knowledge.awktest/cases/73_knowledge_nodes.sh
Not: EdgesThe manifestAny full Markdown parser
Depends on: I0807
Priority: p1
Profile: deep-work
Parallel safe: false
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-04T17:59:30Z
Started: 2026-09-04T17:46:56Z
Verified: unknown: the record declares no `verified_at`
Completed: 2026-09-04T17:59:30Z

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.