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

I0810

A content-hash manifest that makes a second sync cheap

Where it stands

devtask.issue

Readiness: cancelled withdrawn
Status: CANCELLED
Can start: not now
Milestone: M003
Milestone status: ACTIVE
Wave: 4
Waiting on: none
Holds back: none
Behind it in all: 0
Evidence: 0 of 2

Moves

plan.transition

What it is

Objective: Implement the manifest: one row per source with its path, content hash, extractor version and the node ids it produced, written beside the generated graph, compared on every sync, and used so that a sync with no source change does no extraction and says so.
Why: Without a manifest, every query is tempted to rebuild and every rebuild is a full one. The manifest is what makes staleness detectable without mutating anything, which is what lets the read-only commands stay read-only.
Now: Nothing is generated and nothing is cached. The site generator's --check mode is the precedent for a command that reports drift between canonical input and derived output without regenerating it.
Wanted: `knowledge sync` writes the manifest with the graph. `knowledge sync --check` compares source hashes against the manifest and exits non-zero when they differ, writing nothing. `knowledge status` reports fresh or stale and names the sources that moved. A no-op sync is measurably cheaper than a cold one, and the measurement is recorded.
Done when: Cancelled 2026-10-04 on master f075170530: the subject of this issue never came to exist. `majordomus knowledge` has no sync and writes no graph, so there is nothing for a manifest to make cheap or to report stale. Its subcommands (sources, nodes, edges, derive, candidates, promote, reject, check) derive what they answer from the version-control index on every read, and every Rust reader builds the object index in process (1705 objects, diagnostics 0). Nothing under .ai/repo/knowledge is a generated graph: the directory holds candidates/, curated/, README.md and sources.yaml. The read is not free (`knowledge nodes --json` took 48.9 s real at load 42), but that is the cost of one reader, not of a missing sync manifest; if it matters, it is a new issue against that reader. I0811 now depends on I0809, the predecessor this issue had.
Risk: If a no-op sync is not materially cheaper than a cold one, the manifest has failed and should be removed rather than kept as decoration. The measurement is the acceptance criterion, not the design.

Acceptance

A second sync with no source change reports no work and leaves the generated files byte-identical
Editing one source changes that source's manifest row and the nodes derived from it, and no other row
sync --check writes nothing and exits non-zero when a source has moved
The extractor version is part of the manifest, so a change to the extractor invalidates it
The measured cost of a no-op sync and of a cold sync on this repository is recorded as evidence

Validation: bash test/run.sh 68_knowledge_manifest
Evidence required: sync_idempotentnoop_is_cheaper
Evidence present: unknown: the record carries no `evidence` entries

Scope

Touches: lib/knowledge.shlib/knowledge.awk.gitignoretest/cases/68_knowledge_manifest.sh
Not: SearchAny automatic rebuild triggered by a read
Depends on: I0809
Priority: p1
Profile: implementation
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-10-04
Started: unknown: the record declares no `started_at`
Verified: unknown: the record declares no `verified_at`
Completed: unknown: the record declares no `completed_at`

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.