_createCard interpolated n.badge raw into innerHTML while every neighbouring field, including n.app, n.title, and n.message, was escaped, so a caller could inject markup through the badge. The value is caller-controlled end to end: sol notify --badge is free-form and websocket.js forwards raw callosum payloads into show().

_updateCard already assigned the badge with textContent, so initial render and update render disagreed. This aligns them on the safe behaviour.

Found while auditing the icon-contract change. It is the same class of defect that change closes for icon, in the same renderer, but a different field, hence a separate commit.

The test helper assertNoPayload was tightened to match event-handler markup only inside a real tag, because correctly escaped output legitimately contains the literal text onerror.

The notification icon contract is now a Lucide icon name, not an emoji. Emitters in JS, Python, and sol notify help send names; the renderer resolves names to vouched SVG and never renders the caller's value as markup. A legacy glyph-to-name table keeps already-persisted localStorage['solstone:notification_history'] entries rendering correctly; that is a migration path for external data, not a backwards-compatibility shim.

The honest price is that this route deliberately manufactures window.ConveyIcons.svg('name') literals inside the notifications object whose only consumer is the guard test's allow_list <= used direction. It trades a one-line regex change for a hand-maintained duplicate list that must stay in sync with CONVEY_ICON_NAMES, and it narrows the notification namespace from 36 available names to 13. It is the right call here because the safety property - a caller can never inject markup through icon - is worth it. It is not parity with L3's genuinely-free zero-mechanism route, and a later session must not read it as precedent for always manufacturing literals.

D5 and D6 were fixed, not deferred. ERROR_ICON in SurfaceState was a hand-rolled inline triangle-alert SVG; it now uses window.ConveyIcons.svg('triangle-alert'). _updateCard never refreshed the icon even though show() updates existing.icon for keyed notifications - invisible while both were the same emoji, but a stale icon under resolved SVG. It now refreshes from the resolver.

The browser Notification icon member was dropped because it is specified as a URL; the old emoji was parsed as a relative URL and fetched, which always failed. Title, body, and tag still deliver.

The sandbox marker refusal matrix takes a before/after repository inventory for
each of nine cases. target and dist were walked, so on a working clone the walk
covered ~44k entries, core/target alone contributing ~23k files at ~7 GB, and
eighteen full walks pushed the test past pytest 15s timeout. A clean checkout of
the same commit walks ~73 MB and the same test passes in 1.75s, so the verdict
depended on how much the clone had been built in rather than on the product.

target and dist are build outputs, not repository source, and cargo and uv
rewrite them constantly. That is the same category as the .venv and cache
entries already in this set, whose name says runtime dir names.

The exclusion cannot blind the check: tests/test_repo_inventory.py parametrizes
its visibility cases over this set, so both new names automatically gain the
proofs that a regular file, symlink, or fifo with that basename stays
inventoried and that a symlink by that name is not followed, alongside the
existing proof that ordinary writes are reported. 99 inventory tests pass.

`solstone-core` is a maturin package whose Rust sources live outside its
package directory — maturin is pointed at ../../core. Nothing that watches
the build watched there, so two gates were both open:

- uv's default cache key for a path dependency is that package's own
pyproject.toml, so `uv sync` reported "no changes" after a Rust-only
edit and left the previously built binary installed;
- `.installed`'s prerequisites did not move either, so make short-circuited
and never called uv at all. PYTEST is $(VENV_BIN)/pytest, not
`uv run pytest`, so nothing else triggered a sync.

Any environment whose .venv predated a native change kept executing the
older binary while `make ci` reported green. test_make_skills_idempotent is
the only test that copies and runs .venv/bin/solstone-core, so it was the
only one to notice — a pre-port binary has no native `skills` command,
routes to the removed Python delegation, and exits 78.

Declare the real build inputs as uv cache-keys so a sync rebuilds, and add
a content-hashed .rust-core-hash stamp so `make install` runs a sync at all
after a Rust-only change. Both halves are required; cache-keys alone never
fires because make short-circuits first.

Also stop swallowing the binary's own explanation in the idempotency test.
check=True raises CalledProcessError, whose pytest summary carries the exit
status and nothing else, discarding the one sentence that named the cause.

Cut from the root project version and propagated derived packaging state via
scripts/render_packaging.py and uv lock; no hand-edited derived files.

1.0.17 exists to carry 5a803f789, the setup access-surface fix. 1.0.16 shipped a
journal setup that failed two of its own steps and exited non-zero, which hangs
the macOS app first-run onboarding. The changelog bullet names the owner-visible
effect on both surfaces: a setup that reported a problem when nothing was wrong,
and a new Mac install that could wait forever at the last step.

setup built skills_user, skills_journal, and brain_bootstrap as
sys.executable -m solstone.think.sol_cli <cmd>. That module entry is
journal_main, i.e. always the journal surface, and since 4f0d20722 added the
generated access-command rejection the dispatcher exits 2 for skills and call.
So journal setup failed two of its own steps and exited non-zero on every run.

On an installed host that was merely loud: the service still came up. In the
macOS app first-run onboarding it is fatal. The ritual waits for a setup that
reports completion, setup never writes completed_at, and the install hangs.
Observed on ja1r as five paired-profile lanes stalling at setup_step brain for
600s with skills_user and skills_journal failed in setup-state.json. It is a
1.0.16 regression: 4f0d20722 is in v1.0.16 and not v1.0.13, which is why the
7/24 macOS gate passed on the same setup.py.

Route all three through a new sol_console_command, mirroring the existing
journal_console_command precedent. sol ships beside the interpreter in the same
bin dir and owns the access surface.

The existing expected_* helpers asserted the broken argv verbatim, so they
green-lit the regression; they now assert the sol form. Added an invariant test
anchored to the generated JOURNAL_ACCESS_ONLY_COMMANDS inventory, so a newly
added access command cannot silently reintroduce this. It fails against the old
form. Note the 61 rc==0 assertions in this suite all patch subprocess, so they
never execute the dispatch and could not have caught it.

The batch-3 fix (0dbcb0d67) added a 12px horizontal component to .link-modal's padding shorthand. That component was cosmetic.

It narrowed .link-modal-box (width: 92%) from 331px to 309px at a 375px viewport, which produced 9px of internal horizontal overflow (scrollWidth 318 vs clientWidth 309) because the QR panel is effectively fixed at ~294px and was being clipped.

Zeroing only the horizontal component restores the box to 331px with scrollWidth == clientWidth, and the QR panel fits inside the box.

.link-modal-box { width: 92% } supplies the side gutter on its own; at every viewport that 4%-per-side gutter is at least as wide as the 12px removed.

The vertical components calc(var(--facet-bar-height) + 12px) and calc(var(--app-bar-height) + 80px) are unchanged; they keep #link-pair-cancel clear of the fixed chat bar.

Constrain `.link-modal` to the band between the facet bar and chat bar and let `.link-modal-box` scroll internally, so `#link-pair-cancel` is no longer painted under the fixed chat bar.

Cap the `is-glasses` QR at `min(100%, 360px)` instead of `100%`, so the modal no longer overflows the viewport.

Add `DEVICE_LABEL_PLACEHOLDER_COMPUTER` and set the `#link-device-label` placeholder from the selected presentation mode in `setPairCopy()`. The placeholder seam runs before a pair request exists because `setPresentationMode()` calls `setPairCopy()` ahead of `renderPairPresentation()` and its `!currentPair` guard.

Co-Authored-By: OpenAI Codex <codex@openai.com>

The mixed-writability hazard test previously detected root and returned before asserting anything, so under root execution, which is live in this repo, AC 12 had zero coverage while showing green.

Add a root-proof variant that places a regular file at one agent's skills-root path. mkdir through a non-directory component fails with ENOTDIR for every uid including root, so the vector runs everywhere with no chmod and no seam. It asserts the writable agent still installs, that an error row names the unwritable agent and path, and exit status 1. The row reason is deliberately not byte-pinned, because permission failures use Rust-native io::Error text under the divergence recorded in 9663b6445.

Retain the chmod-based test for the true permission-bits case, and make its root skip loud rather than silent so a root run reports the gap instead of showing green.

The negative control was verified: temporarily inverting the new test's exit assertion made it fail with exit 101 and left: 1 right: 0, confirming the test can actually fail.

Remove a redundant !is_symlink() clause from a symlink_metadata-sourced check in the tree walk, where is_dir() is already false for symlinks.

Co-Authored-By: OpenAI Codex <codex@openai.com>

Relocate _discover_project_sources and _ROUTER_SKILL_NAMES into solstone/think/doctor.py rather than sharing them, because doctor is still Python and must not shell out to the native binary. They are knowingly duplicated with core/crates/solstone-core-sol/src/skills.rs, and that duplication ends when doctor itself is ported.

Exactly one assertion is knowingly dropped for a reason other than the build verb removal: the duplicate-router-name ValueError branch from the original skills_cli.discover_project_sources. It is unreachable now that the required payload names are a declared constant of two distinct literals.

The build verb is removed from the CLI surface as a deliberate, operator-approved change. Its sys.path.insert plus from scripts import build_skill_references scaffolding is deleted outright, not ported. make skills invokes scripts/build_skill_references.py directly as of the preceding lode.

Delete scripts/capture_skills_parity_oracle.py in this same commit. The harness drives solstone.think.skills_cli directly: it subprocesses python -m solstone.think.skills_cli and monkeypatches skills_cli.get_project_root and skills_cli.resources.files. Once that module is gone, the script cannot run at all; it would be dead code, not merely stale. Its provenance role is fully preserved: the harness and the 30 vectors it produced are committed together at 5240cfaaf, strictly before this deletion, so git log over core/fixtures/native-sol/skills-parity-v1/ still proves the vectors were captured from the live Python oracle. The frozen vectors themselves remain in the tree and continue to gate the native implementation.

Leave solstone/think/setup.py deliberately untouched. Its skills_user_command() and skills_journal_command() build python -m solstone.think.sol_cli skills install ..., but skills is in JOURNAL_ACCESS_ONLY_COMMANDS, so sol_cli rejects it with exit 2 and journal setup reports both skills_user and skills_journal as failures. That defect predates this lode and is left for a follow-up; tests/test_setup.py and tests/test_setup_jsonl.py pin the current argv shape and pass unmodified.

Co-Authored-By: OpenAI Codex <codex@openai.com>

sol skills install, uninstall, and list now run through a direct match arm in solstone_core_sol::run, placed before the compatibility dispatcher. It is not a native authority entry: the inventory builder globs solstone/**/native/**/authority.toml, every entry lands in a partition with a frozen count, and sol-call paths must exist in the frozen oracle grammar. skills is a top-level non-call verb with no oracle path.

Remove skills from TOP_LEVEL_COMPAT_MODULES and TOP_LEVEL_COMPAT_COMMANDS, one element each. The compatibility dispatcher, the SOLSTONE_NATIVE_COMPAT_ACTIVE sentinel, and every other compat entry are untouched. A new order-insensitive, count-free element-identity assertion ties the two collections together so they cannot drift.

One Python/Rust divergence is knowingly accepted: install_user does not reproduce the os.access(target, W_OK) pre-check. access(2) has no std equivalent and adding libc to reproduce one error string is not warranted. The filesystem outcome is identical: a mode-0500 directory fails remove_dir_all immediately with no partial deletion. Only the reason string differs, and it is Rust-native. AC 12 is covered structurally by a hazard test rather than byte-pinned.

The project root is canonicalized inside the skills path only, matching Python's get_project_root() realpath so lexical relpath targets agree. resolve_project_root(), sol root output, and check-native-sol-root-contract are unchanged.

skills.rs is added to CORE_REQUIRED_SDIST_MEMBERS in scripts/check_wheel_contents.py because a new solstone-core-sol source file must ship in the core sdist.

Co-Authored-By: OpenAI Codex <codex@openai.com>

Capture 30 parity vectors by running the live Python oracle in solstone/think/skills_cli.py through scripts/capture_skills_parity_oracle.py. These vectors are generated evidence, not hand-written fixtures.

This lands before that Python module is deleted later in this lode, so git log over core/fixtures/native-sol/skills-parity-v1/ proves provenance. A fixture set reconstructed by reading deleted code would not be evidence.

The harness deliberately has no --check mode and is not wired into make ci. Its oracle is deleted two commits later, so such a gate would be permanently red; this is a deliberate divergence from the scripts/build_journal_resolution_vectors.py precedent.

stdout and stderr are captured as separate streams. argparse's own usage/help/error message bodies and Python OSError.__str__ errno renderings are deliberately not pinned; for the exit-2 usage vectors only the exit status is asserted.

Co-Authored-By: OpenAI Codex <codex@openai.com>