verify_claims.py gives all 813 claim rows a mechanical disposition; the 28 flags were adjudicated by hand (REPORT.md appendix). Two survived as genuine drift (F-017): a closed issue still described as open in shared/lab-netzwerk.md, and a 'pending' decision block in hosts/cfgmon.md whose premise the same file records as executed. Also: narrow the vendored-path filter (it silently dropped 7 tracked icon files and produced false path-miss flags), record the confirmed canonical author identity in F-003, verify the Gitea#48->GitLab#46 numbering shift by title in F-005, and add the ADR-0010 draft under analysis/drafts/ for the human to git-mv into decisions/. Branch renamed to Neckbeard-v0.1.1-analyse-1 per the human.
3.7 KiB
F-017: Prose still asserts work-item states the tracker has already resolved
category: doc-drift confidence: high
Found by the systematic claim-verification pass (analysis/scripts/verify_claims.py
-> analysis/data/claims_verification.tsv), which gave all 813 extracted claim rows a
mechanical disposition; the 28 flagged rows were adjudicated by hand (REPORT.md appendix).
Two survived as genuine drift; a third observation rides along.
evidence:
- A closed issue described as open.
shared/lab-netzwerk.md:118-120: "Zwei Punkte … bleiben offen: [#13] … und [#15]". management#13 (LABNET-03) is closed,closed_at2026-08-02T13:43Z (analysis/data/gitlab_issues.json); #15 is indeed open. The doc's last commit is dated 2026-08-02 12:00 UTC — but that timestamp is the anonymised one (CLAUDE.md:122-128), so whether the sentence was already false when written or became false minutes later is undecidable from the repository: the anonymisation rule destroys exactly the evidence a freshness analysis needs. What is decidable: seven days later it still says "offen". - An open decision whose premise was already executed — in the same file.
hosts/cfgmon.md:119-124("### Entscheidungsabhängig") makes removing thethread-net-gitrunner dependent on "ob das gitops-Repo seinen leichtendeploy-on-push.yml… behält".hosts/cfgmon.md:61records that gitops removed.gitea/workflows/entirely (commit5e46a24; verified: the commit deletes exactlydeploy-on-push.yml+milestone-release.yml, andtree_axion1337.chat-gitops.txtcontains no.gitea/today), andhosts/cfgmon.md:70-75records the runner removal as done. The "pending" decision block outlived its own answer by 60 lines. - Bare issue references default to the wrong project.
hosts/cfgmon.md:63"siehe #33" andverfahren/aar/2026-08-09-refinement-und-betrieb.md:60"#60" carry no project. UnderREADME.md:47("Alle offenen Punkte sind Issues in diesem Projekt") a reader resolves them as management#33/#60 — neither exists. Both resolve by content to gitops issues (gitops#33 "Gitea Actions Workflows existieren, laufen aber nie…" matches the dead-workflow context; gitops#60 "Blueprint matrix-recovery-flow … Passwort-…" matches the password-recovery diagnosis). Content correct, address ambiguous.
impact: Small per instance, but these are precisely the rows a systematic sweep exists to find: each is a sentence a reader would act on (reopen a closed question, wait on a dead decision, search the wrong tracker). Instance 1 also shows a structural side effect worth naming for Session 2: the timestamp anonymisation makes "was this claim true when written" an unanswerable question for every doc-vs-tracker discrepancy on the same day.
root-cause pattern: Decision executed in the tool, documentation not carried along (pattern A) — here at sentence granularity rather than document granularity.
neckbeard mechanism: Partly covered, partly gap. Under ADR-0002
(docs/adr/0002-in-repo-issues.md) an issue reference is a relative link to
docs/issues/NNNN-slug.md — instance 3's ambiguity cannot exist, because
scripts/validate.py check_body_links fails on a target that is not there. For
instances 1–2 the framework has the rule (WORKFLOW.md:136-138, contradictions never
left silently coexisting) and the ritual (WORKFLOW.md:126, wiki lint for "claims
superseded by newer sources"), but no deterministic check compares a prose assertion
("open", "pending") against the frontmatter status of the artifact it points at —
that specific check is a neckbeard gap, and verify_claims.py's expectation-word
logic is a working sketch of it.