[conformance/nits] Sweep the surfaces/tools nits: check-kind discovery, retirement census, and orphan-guard spec homes

[StarshipSuperjam]

The engine opened this item itself — you didn't create it.

What this is. A conformance audit of the build against the locked engine-planning design confirmed the divergences below (re-verified against current main) and grouped them into one build-session-sized unit for the surfaces-tools subsystem.

The low-severity items across the surfaces/tools family. The check validator hardcodes its kind REGISTRY to the core kinds and does not implement the presence-discovery the check README promises for a module-provided kind (loud fail-closed today, no v1 module ships a kind, so nothing is stranded -- but no decision scopes the mechanism out of v1). Two construction-only artifacts are missing from the v1 retirement census: a stray construction demo (demo_map_reachability.py) whose behavior is already regression-tested yet travels into every generated repo with no declared fate (one of nine such standalone demos), and a construction-scoped guard (memory_pointer_public_safety_check.py) that no-ops in deployed repos with no spec home. And seven build-side tool guards do their job well but have no home in the design canon -- each is a hardening beyond the spec's letter or a well-built check the spec never names -- sharing one risk: a future spec-faithful rebuild has no doc telling it to keep these protections. A build session realizes check-kind presence-discovery, adds the stray demo/guard to the retirement census (keep or drop, explicitly), and gives each orphan guard a one-line spec claim or logged decision. Note: homing several orphan guards touches locked/settled docs (litigation-class in aggregate) -- frame honestly as improvement_relitigate/spec_gap, never a silent build change; the orchestrator should confirm the spec absorptions. None of these is tracked by an open issue.

Findings in this unit:

• U07: add presence-discovery of a module-provided conforming kind callable to the validator's kind registration, matching the check README's file-drop contract

• U13: add demo_map_reachability.py (and audit the other eight standalone demos) to the first-run retirement set or retire it since its behavior is regression-tested; record memory_pointer_public_safety_check.py on the v1 construction-layer retirement census with an explicit keep/drop disposition

• U14: give each orphan build-side guard a spec home -- a one-line claim in the owning README or a logged decision (agent_coherence_check read-only write-tool leg; shared github_client; uv_group_drift gate; weakening_guard listing-cap completeness property; knowledge_vocabulary_check; audit_soft_findings feed; untracked_surface signal) -- so the protections are traceable; no build behavior changes

• Spec authority: systems/surfaces/check/README.md L84-88 (a module adds a kind by a conforming callable discovered by presence, not a wiring seam); decision-log.md D-112 / Q26-resolution L847; decision-log.md D-228 (a construction demo does not travel unless promoted; retired once a permanent regression test covers the behavior); the construction-repo retirement census (first-run-assets.json); systems/surfaces/agents/README.md:63-64,104-123; systems/guardrails/templates/README.md:38-39 + audits/README.md; wbs/stage-0-harness.md:118,135 + principles sec15; systems/cognitive/knowledge/README.md

• Quality attributes: Composability, Auditability, Trustworthiness-for-a-non-engineer, traceability

What happens next. A single build session should clear this batch of low-blast-radius nits together. The engine opened it for your review.

More detail.

• Full build-conformance audit (delta report)

[StarshipSuperjam]

Nit surfaced during #405 Sub-PR 1 (PR #428) — schema-check messages lead with a raw jsonschema fragment before the operator copy

The four-lens deliverable-gate review of PR #428 surfaced a pre-existing, repo-wide operator-communication nit in the schema check kind. It fits this sweep's validate.py check-kind theme, so recording it here rather than opening a new issue.

What happens. kind_schema (.engine/tools/validate.py:415-431) prepends the jsonschema library's raw technical fragment before the rule's plain-language message. On a mis-shaped or unparseable file the operator's finding reads, e.g.:

• '.engine/provisioning/first-run-assets.json' does not match its schema at (root): 'directories' is a required property. <plain message>
• '…first-run-assets.json' is not valid JSON and cannot be schema-checked: Expecting property name enclosed in double quotes: line 1 column 3 (char 2). <plain message>

The leading clause (does not match its schema at (root), is not valid JSON and cannot be schema-checked, the char-offset, the raw err.message) is engineer shorthand the "What the operator is told" law bars from the surface — and it lands before the plain copy the rule author wrote.

Scope. Repo-wide: every schema-kind check (~15 rules) routes through this one function, so the fragment prefixes all of them. Not introduced by any single rule.

Possible disposition (for the sweep, not prescribed). Lead with the rule's plain message; drop the raw fragment from the operator line or demote it to a secondary/parenthetical position, so the first thing the operator reads is the plain-language consequence + fix.

Provenance. Surfaced by the deliverable-gate review of PR #428 (#405 leg 4); ground-truthed against .engine/tools/validate.py:415-431 on current main. Out of scope for #428 (a repo-wide validate.py change, not the manifest guard).