The docs-fact census wave re-read the live hosts and re-keyed every page it could: runtime/payload identities, ports, sizes, ledger figures, unit state, and the retirement banners that drifted as the fleet moved. The wave was interrupted mid-run, so this commit carries only what passed the integrity gates: every touched page parses (front matter or H1+status convention intact, balanced fences, no truncated tables, trailing newline), the docs_completeness and link-integrity seams are green, and bats is 384/384. Numbers that this session proved on live hosts are keyed to the measured value, not the page's earlier claim.
5.2 KiB
type, title, description, tags, timestamp
| type | title | description | tags | timestamp | |||||
|---|---|---|---|---|---|---|---|---|---|
| reference | Agent Docs and Edits | Two self-inflicted damage classes — structurally broken markdown after parallel agent edits, and botched hashline PUT/CUT repairs — with the audit checks and recovery order for each. |
|
2026-10-18T00:00:00Z |
Agent Docs and Edits
Doc-structure audit (after parallel agent edits)
Use after one or more subagents have edited markdown docs (OKF/Obsidian
vault with --- frontmatter), before committing. Link checkers and
completeness seams validate references, not structure — agents reliably
produce structurally broken markdown that still links cleanly.
Damage catalogue:
- Banner/prose prepended above the opening
---→ the frontmatter is no longer frontmatter (title/tags/description become body text). - A rewrite appended instead of merged → duplicate headings and a stray
second
---mid-file. - Literal model artifacts in the body:
<|channel>}<tool_call|>...,+-,- -. - Wrapped bullets re-emitted with a
-prefix on every physical line. - Line-range replacement that dropped a sentence tail → dangling fragment, often mid-parenthesis.
Checks (fast, run all):
head -3 <file> # must be `---` if the page has frontmatter
grep -c '^---$' <file> # exactly 2 (opener + closer)
grep -n '^## ' <file> | sort -t: -k2 | uniq -f1 -d # duplicate sections
grep -rnE '^\+- |^- - |<\|' <files> # artifacts
python3 scripts/check-vault-links.py <vault-dir>
./tests/run.sh # docs completeness seam etc.
Repair order (matters):
- If the file was destroyed rather than edited: stash the agent version to
.AGENTTRASH/<YYYYMMDD-topic>/, thengit checkout HEAD -- <file>and re-apply only the intended changes by hand. - If it merely duplicated: salvage unique content first — cut the one-of-a-kind section, paste it into the copy you keep, THEN delete the duplicate ranges. Never delete first.
- Re-add missing sentence tails (insert before the orphaned fragment), keeping list continuation lines indented.
- Re-run all checks above.
Gotchas: agents can write AFTER they appear finished (job settles, file
changes) — re-verify structure after the last background job reports, not
before. Editing an agent's already-damaged file with fresh line numbers is
safe, but its snapshot tag changes on every edit — re-read before each
subsequent edit. .AGENTTRASH/ is gitignored (.gitignore:25), so NEW trash
stays local — but do not read that as "the repo has none of it": on 2026-10-18
git ls-files | grep -c AGENTTRASH returns 37 tracked paths
(.AGENTTRASH/, scripts/.AGENTTRASH/, dankserver/.AGENTTRASH/,
tests/.AGENTTRASH/), because gitignore never untracks what was committed
before the rule. Trash is a temporary hold, not an archive.
Hashline edit recovery
Failure mode: multi-op edits resolve every PUT N.=M: / CUT N.=M: index
against the original file numbering, and the post-apply diff view
elides lines (it shows an anchor window, not the whole file). Two traps
follow:
- A second edit call built from a diff-view snapshot uses line numbers from a partial view. Lines outside the window are invisible but still counted.
- If the first apply was itself wrong, the file shifted. The diff view tells you the damage, but not the true offsets.
Result: the repair pastes fresh text beside stale text instead of over it.
Procedure:
- Never carry line numbers across calls. Re-read the target range for a fresh tag before every subsequent edit. A read is cheap; a duplicated paragraph costs a commit and a revert.
- One op per call when the previous apply was imperfect. Fixed offsets are only trustworthy when every preceding apply landed exactly as specified.
- Re-read after every apply, and verify the whole affected region — the diff view is a sample, not proof. Check the boundaries: the line before the edit and the line after it. Damage shows up as a repeated sentence straddling the seam.
- Repair by CUT, not by re-PUT. Once you know the exact stale lines from a fresh read, delete them. Do not try to PUT a corrected superset over a range whose extent you are guessing at.
- Verify with a content assertion, not a diff review:
grep -cfor the duplicated sentence, plus a syntax/compile check on any touched script.
Same rule for any imperative edit tool with an old/new match: the matched
text must be the entire text being replaced. Matching a bare fragment
inside a paragraph splices the replacement into the middle of the sentence
and silently corrupts the file. Re-read the file afterwards to confirm.
Anchored in-page links
Renaming a Markdown heading breaks [[#Old Heading]] anchors. When a
section is retitled, grep for the old heading text and fix every anchor in
the same pass — doc link-checkers frequently do not validate #fragment
targets, so a green suite will not catch a dangling one.
Related
- OMP Harness — the session context these repairs protect
- Command Center Dotfiles — the repo these edits commit to
- Testing Policy — the seams that catch broken vault structure