`spec edit` nulls abstractOriginHash instead of re-stamping it — disarms the staleness detector on every spec it touches

[shadowbrush]

Found while re-grounding the cor:api:040 and cor:rag:010 specs in hadronmemory.com::specs.

What happens

hadron spec edit writes the abstract but leaves abstractOriginHash NULL rather than stamping it with the hash of the content the abstract was just written against.

Reproduced on every node edited in that session — after spec edit with --content-file + --abstract-file:

$ hadron node get hadronmemory.com::specs::cor:api:040:01 --json | jq .abstractOriginHash
null

Why it matters

Per spec 032, abstractOriginHash is "a fingerprint of the content value at the time abstract was authored", and the Source: abstract-stale marker fires when that hash disagrees with the current content hash — and only when the hash is non-null. So a NULL hash doesn't mean "fresh"; it means "never claim staleness for this node again."

The effect is backwards from the intent. spec edit is the right moment to re-arm the detector — the author has just reconciled body and abstract, which is exactly the state the hash is supposed to record. Instead the tool clears the signal, so:

• The stale flag disappears, which looks like the fix worked.
• The node is then permanently exempt from staleness detection, including for every future edit made by any other tool.
• The nodes losing the detector are the actively-maintained ones — the ones whose abstracts drift most.

This may explain a corpus-wide pattern: a large share of the ~259 specs in hadronmemory.com::specs currently show Source: abstract-stale, while maintained ones show a NULL hash. Worth checking whether the corpus has been quietly split into "flagged forever" and "never flagged".

Expected

When spec edit writes the abstract, stamp abstractOriginHash with the hash of the content as of that write — the same value the server computes on a normal abstract-authoring path. If the CLI shouldn't compute it locally, the server-side update should own it; either way the invariant is writing an abstract re-bases its origin hash.

Worth confirming which layer is dropping it: the CLI's update call may simply be omitting the field, in which case the server's node-update path may also need to re-stamp on abstract writes rather than leaving it to callers.

Also worth a look

spec edit skips a field whose value is unchanged ("a field that didn't actually change is not rewritten"). Combined with the above, there's no way to re-stamp the hash after a body-only edit without making a cosmetic change to the abstract — which is what I had to do. A --restamp-style affordance, or re-stamping whenever the body changes and the author confirms the abstract still holds, would close that.

Refs

• Spec cor:dmo:020:03 — the staleness signal.
• Spec cor:dmo:020:02 — the abstract field.

🤖 Generated with Claude Code