agent-spec documents aware.units() as shipped; nothing in the runtime or atoms implements it

[pawellisowski]

The gap

10-core/agent-spec.md (lines 329–337 on main @ f8d213f67) documents a unit-typed numeric helper as a shipped part of the expression engine, with worked code:

const dead = aware.units('4.0 kN/m^2');
const live = aware.units('2.5 kN/m^2');
return aware.units(dead.plus(live));   // returns "6.5 kN/m^2"

Mixing kN/m² with kN/m or m would throw at run time, not produce silent garbage. The expression engine ships with the SI base + derived units library; per-discipline conventions (kip, klf, kN/m) round-trip cleanly.

Nothing implements it.

Verified

On origin/main:

git grep -n "aware\.units" origin/main -- 10-core          # 3 hits, all in the spec's example
git grep -n -E "units\s*\(|fn units" origin/main -- cli/src atoms 20-agents/_core   # 0 hits
git grep -n -i "units" origin/main -- cli/src/runtime atoms                         # 0 hits

The only units in the runtime are viewer-3d scene metadata strings (cli/src/render/viewer_3d.rs:2649, 20-agents/_core/viewer-3d/skills/scene-schema.md:16), which are labels, not a units library. No atom under atoms/ handles units.

Why it matters

A map node written from the spec's own example fails at run time with an undefined aware.units. Any agent author following the documented contract hits it on first use. It also matters downstream: floless.app is planning server-recomputable elevation provenance for steel reads (pawellisowski/floless.app#1029), where feet-and-inch ↔ millimetre handling is exactly the kind of unit-typed arithmetic this helper promises; with no substrate primitive, that stays app-side (first consumer), and the spec's promise is the thing a second consumer would look for.

Expected

Either the expression engine ships the helper the spec describes (SI base + derived units, discipline conventions, throw on unit mismatch), or the spec stops describing it as shipped and marks it planned.

Found while studying main for the floless.app elevation-provenance plan, 2026-09-02. Not a floless misuse: no floless code calls it; the spec was read as the source of truth for what the runtime owns.

[pawellisowski]

🤖 Picked up by the morning issue routine on cloud-issue-routine-aware at 2026-09-03T04:05:00Z.

Another machine reading this issue will skip it while this claim is live (it expires after 14h). The claim is released when the run finishes, whatever the outcome.

---

Generated by Claude Code

[pawellisowski]

🤖 Morning issue routine on cloud-issue-routine-aware: claim released. Outcome: fixed and merged — PR #486, squashed to e5dc8644 on main. Leaving this issue open as qa-ready; the PR used Refs #484, not a closing keyword.

Release marker (plain text, since HTML comments are stripped on this transport — see note below): release of claim comment 5520412093 by machine cloud-issue-routine-aware.

What was fixed

Not by implementing aware.units(), but by the alternative this issue itself offers — the spec no longer describes it as shipped. Implementing it is a new runtime, not a bug fix: the worked example is unreachable for two independent reasons, and the second is structural.

• cli/src/runtime/inline.rs is a predicate evaluator (paths, literals, ==, !=, &&, ||) with no function-call and no arithmetic syntax, so aware.units('4.0 kN/m^2') cannot tokenize.
• cli/src/validate.rs:843 rejects any inline node whose kind is not predicate (E_APP_INLINE_KIND). The example is a map node, so it fails at validate/compile before the missing helper is ever reached.

The wider finding

Investigating the reported symptom turned up that the entire v0.21 engineering envelope is a published schema with no behaviour, while cli-roadmap.md:31 marked it ✅ shipped. Verified by reading the tree:

Claim	Reality
aware.units() ships with the SI units library	no implementation in cli/src or atoms/
signed-output topology node	not a node kind — Node has no such field and no deny_unknown_fields, so serde discards it silently; not even rejected
engineering.output-seal writes .aware-receipt.json	OutputSeal typed but never read; no receipt written
app engineering.pins validated at install vs the agent's pinnable set	never compared at install, compile or run; copied verbatim into the lock
agent engineering.pinnable resolved by the transport binary	parsed and never read — manifest/agent.rs:20 already said so in-tree
pin values "appear in the provenance log"	the provenance writer records no engineering pins

Fixing only aware.units() would have made the doc more misleading, since marking one item planned implies its neighbours are shipped. So the correction covers the section; the roadmap row is now 🟡 schema only, matching the wording v0.19 already uses one row up. Every worked example is kept — status: planned exists precisely to keep the contract published. Signing itself genuinely ships as aware key + aware receipt sign|verify (ed25519), and the note points there, so the gap isn't overstated.

Review + gates

Codex reviewed and raised one P2 — that "every key is accepted and type-checked" overclaimed, since signed-output is unmapped. Verified and fixed at root in ad7f8a72; Codex then passed clean on that exact commit ("Didn't find any major issues"). CI green 14/14 on the same sha; cargo fmt, cargo clippy -D warnings and cargo test --locked all pass locally on the pinned 1.95.0 toolchain.

⚠️ Note for whoever maintains routine-claim.mjs

HTML-comment markers do not survive this environment's GitHub transport. The cloud routine reaches GitHub only through the MCP server, and comment bodies read back with <!-- ... --> stripped — so a claim posted here is invisible to any MCP-based reader, and the lock silently degrades to no lock. Two earlier runs' markers on #481 read back stripped the same way. It didn't bite today (this issue had zero comments, so the claim was uncontested), but two cloud machines running concurrently would not see each other. Worth a plain-text marker form alongside the HTML one.

---

Generated by Claude Code