Field findings from the first real legacy migrations: stale-vintage stamp dispatch, silent wiki-absent session start, README memory-path snippet

[psaboia]

Three small defects surfaced while migrating real adopted hosts (paper-atomizer, PRs #110/#111 there) and verifying the fresh-clone onboarding flow. None is covered by existing fixtures because each needs a version/environment combination the sandboxes don't reproduce.

1. adopt's --stamp-missing-templates dispatch runs the HOST's init-wiki.sh, which may predate the flag

The already-present branch (adopt.sh, added in #76) calls bash wiki/init-wiki.sh --stamp-missing-templates — the host's copy. On a legacy host that copy is an older REFUSEd vintage that rejects the unknown flag:

• Observed on paper-atomizer (June-28 vintage): Unknown option → exit 1 → Edge-Types.md not stamped; only the adopt-log detail (stamp-missing-templates exited 1) records it.
• The H3/H4 fixtures miss this because their hosts receive the current init-wiki via ADD; the failing combination is pre-existing wiki + pre-flag init-wiki (REFUSE), which only real hosts have.

Fix: the stamp step should invoke the template clone's init-wiki.sh (cwd = target) so stamping is independent of host vintage. Red-first fixture: a host staged with a pinned pre-flag init-wiki (same technique as _fixtures/legacy-update-from-template.sh).

Workaround used in the field: run the stamp again after update-from-template.sh has synced init-wiki to current.

2. session-start.sh is silent when the wiki is absent

When python3 is missing, ensure-wiki.py's registered command no-ops by design (command -v python3 … || true) — but then nothing else speaks up. Observed in a fresh clone without the wiki: session-start.sh prints the generic orientation block (its own comments call blocks 2–3 "skipped silently") and never says the wiki is missing or how to get it. Contrast: when python3 exists and the clone fails, ensure-wiki.py emits an explicit instruction naming the exact clone command.

Fix: when the index/log blocks are skipped because the wiki directory is absent, emit one line mirroring ensure-wiki.py's failure message ("wiki not found at wiki/.wiki/ — clone it with git clone <url>"). A silent skip looks identical to a healthy minimal session.

3. claude-code README's verification snippet computes the memory path with tr '/._' '---'

wiki/agents/claude-code/README.md ("Personal memory seeded?" check) uses ENCODED=$(pwd | tr '/._' '---') — a simplification of lw_claude_project_slug (scripts/lib/claude.sh), which replaces any non-alphanumeric byte and appends a base36 hash for paths >200 chars. A repo path containing other special characters makes the README's ls point at a directory that doesn't exist while setup.sh --seed-memory writes to the correct one.

Fix: have the snippet call the real helper (source scripts/lib/common.sh; lw_memory_dir "$PWD") instead of re-deriving the encoding.

[psaboia]

Fourth field finding — lint checklist doesn't cover log-entry ordering.

During the PRISM migration (PRISM PR #2), the migration's log entry was appended to the bottom of log_PRISM.md — but that wiki's convention is newest-first. The same append had been correct on paper-atomizer and rare-disease-copy, whose logs are chronological-append: the ordering convention varies per wiki, and nothing declares or checks it.

Notably, the violation was caught not by /wiki-lint but incidentally — a Claude Code session in PRISM, answering a routine query about the wiki, flagged it on its own ("that 2026-07-10 entry appended at the bottom breaks the log's reverse-chronological convention"). The canonical Lint checklist (orphans, dead links, stale claims, missing frontmatter, type: untyped, missing cross-references) has no item for log conventions, so detection currently depends on model attentiveness rather than the procedure.

Proposed fix (small):

1. SCHEMA template: have the log_<repo>.md section declare the file's ordering convention explicitly (newest-first vs chronological append).
2. Lint procedure (SCHEMA + /wiki-lint skill): add one check — "log entries follow the file's declared ordering convention".

Fix applied to PRISM's wiki meanwhile (entry moved to top, ed51e35).

[psaboia]

Fifth field finding — init-wiki.sh update mode itself violates the log conventions it writes.

Live case during a /wiki-lint pass on PRISM's wiki: the lint agent ran wiki/init-wiki.sh in update mode (correctly, per "execute the script, don't reimplement") to modernize the May-vintage SCHEMA. The script appended the six missing SCHEMA sections — including the "Log Entry Attribution" section that declares attribution as the first bullet — and then wrote its own log entry at the bottom of log_PRISM.md with generic attribution, in a wiki whose convention is newest-first. The lint agent caught the script recreating, in real time, the exact defect the pass was fixing (see the fourth finding above), and rewrote the entry in place while preserving the phrase the script's idempotency check greps for.

This settles where the fix belongs: not in writer attentiveness, but in the tooling —

1. SCHEMA declares the log's ordering convention explicitly (newest-first vs chronological append), as proposed in the fourth finding;
2. init-wiki.sh's update-mode log write respects that declaration and puts the attribution bullet first;
3. the Lint procedure checks both.

Until then, every update-mode run on a newest-first wiki plants a fresh violation at the bottom of the log.

[psaboia]

Sixth field finding — ensure-wiki.py on a renamed repo clones a duplicate wiki.

The hook derives the wiki path from the origin repo name and checks that exact path (wiki_dir.is_dir() on wiki/<origin-name>.wiki). Live case: crcresearch/AI-Sci-Disc-Mem was renamed at some point — its wiki namespace and team convention remain AI-Sci-Disc-Memory (CLAUDE.md, commands, and every wiki nav file agree on -Memory). On a team machine carrying wiki/AI-Sci-Disc-Memory.wiki/, the hook would see its exact path (wiki/AI-Sci-Disc-Mem.wiki) absent, clone a second wiki checkout next to the first, and from then on every lw_discover_wiki_name consumer (update-from-template, check-template-version, overlay setup) dies with "multiple wikis … ambiguous".

The same divergence also contaminated a first migration attempt on that repo: cloning the wiki under the origin-derived name made the updater substitute {{REPO_NAME}} as -Mem, silently re-pointing the (correct) -Memory references in .claude/commands/* at non-existent paths. Redone with the wiki at the team's directory name; fine.

Proposed fix: before cloning, treat any existing wiki/*.wiki/ checkout as "present" (glob, matching the ambiguity guard's own semantics) — or resolve the expected path from the committed CLAUDE.md reference rather than origin. Until then, hooks were deliberately left out of the AI-Sci-Disc-Mem migration.