STACK-MAP's filekit entry lists four removed symbols and is two minors behind #4

Summary

docs/STACK-MAP.md still describes filekit as it was at 0.3.0. filekit is now at 0.4.3, and the map's L1 section lists four symbols that no longer exist while omitting two capability areas that do. Since the map is the contract the other five libraries read, a stale entry is worse here than in a README.

Surfaced while building filekit's documentation site: drawing its dependency diagram against this map exposed the divergence in both directions.

Owning epic: #3.

1. Four symbols listed that 0.3.0 removed

Measured against the installed package (hasattr(dazzle_filekit, ...)):

All four are in the L1 fns (paths) / fns (utils.compat) rows. The map already records the D3 deprecation in a Notes column, but the symbols remain listed as if callable.

This is the part with real downstream cost: a library designing against the contract could reasonably plan on normalize_path existing.

2. Version header is two minors behind

### L1 `dazzle-filekit` (0.2.4 -> 0.3.0, PyPI ✓, ...)

Now 0.4.3, published to PyPI. Releases since the freeze:

• 0.4.0 — longpath: Windows MAX_PATH shims via on-demand junctions
• 0.4.1 — platform/interpreter guard fixes
• 0.4.2 — is_device_path device/sink predicate; bare-string guards on all five collection-taking entry points (filekit#16)
• 0.4.3 — documentation, Read the Docs site

3. Two capability areas absent from the capability map

grep -c 'longpath\|is_device_path' docs/STACK-MAP.md → 0.

longpath (0.4.0) is arguably a new L1 capability rather than a detail: it is the remedy for a condition utils.validation.is_valid_path only ever detected. shim_path makes a file over MAX_PATH openable by any application by siting a junction at a short root. Worth a row under "Capability ownership (one home each)" — it is the sort of thing another library would otherwise reimplement.

is_device_path (0.4.2) answers "is this string a PLACE?", distinct from is_valid_path's "is this string LEGAL?". /dev/null is a legal path where nothing is ever stored. It came out of Claude-Session-Backup#56, where 2>/dev/null scraped from shell commands was being indexed as a session's top working directory at 119 hits. Any stack consumer harvesting paths from logs or commands wants it.

4. The filekit -> unctools edge reads as weaker than it is

The dependency chain draws it dashed, annotated "peer/extra only (no runtime import)".

Both halves of that are defensible, but together they now understate the relationship. Measured:

• pyproject.toml declares unctools>=0.2.2. pip install dazzle-filekit always brings it. The optional [unctools] extra was removed in 0.3.0.
• Nothing imports it at module load: paths.py and validation.py import inside functions, and _fallback.py — the only top-level importer — is itself imported lazily. import dazzle_filekit succeeds with unctools blocked entirely (verified with a meta-path blocker).

So: always installed, never eagerly loaded. "No runtime import" is accurate about the import graph and misleading about the dependency. Suggest keeping the dashed line but re-annotating it "declared dependency, lazily imported", which distinguishes it from a genuinely optional edge such as preservelib -.-> dzlinklib.

5. profile/README.md — a house-pattern question, not just a link

filekit's entry points "Full documentation" at tree/main/docs. Its docs are now rendered at https://dazzle-filekit.readthedocs.io/ — searchable, cross-linked, with [source] links to the implementation.

No sibling links to a docs site, so this is a convention decision rather than a one-line edit:

• Point filekit's entry at the rendered site and leave the other four pointing at tree/main/docs — accurate, but makes the others look neglected.
• Adopt Read the Docs across the stack. filekit's setup is deliberately portable: only project, html_title and the repo URLs are filekit-specific. Roughly an hour per repo.
• Leave all five as-is and treat the rendered site as an unadvertised extra.

Proposed change: an addendum, not an edit

STACK-MAP is marked v1.0, FROZEN 2026-06-11, and its own convention for changes is an # ADDENDUM block opening with a "Ratified by user:" quote — see ADDENDUM D9a. So this should not be a rewrite of the frozen body.

Draft ADDENDUM D10a:

1. Tombstone the four removed symbols in the L1 rows, pointing at their replacements (matching how A5/A6 handle the unctools and treelib tombstones).
2. Update filekit's row header to 0.4.3 with the release list above.
3. Add longpath and the device/sink predicate to L1's capability rows and to "Capability ownership".
4. Re-annotate the filekit -> unctools edge as declared dependency, lazily imported.

The ratification line needs the maintainer's own words; everything else is drafted and ready.

Acceptance

• No symbol listed in STACK-MAP's L1 section fails hasattr(dazzle_filekit, name). Worth automating — a small script over the map's symbol tables would catch this class permanently, for every layer rather than just L1.
• filekit's version header matches the current release.
• longpath and is_device_path appear in the capability map.
• The unctools edge annotation distinguishes "declared but lazy" from "optional".
• A decision recorded on the docs-site question, whichever way it goes.