DONE Generalize affine-p to a three-valued character #SYUACW

Intent: replace the boolean affine-p on quantity-specification with a character of :point, :absolute, or :difference, add a :non-negative specifier at the definition level, and implement the V3 operation table (#LNRY72) in the arithmetic core — without changing any generated shader module.

Evidence:

• quantity-specification carries a character slot; affine-p survives as a reader (character is :point) and as a constructor keyword. quantity-definition gains non-negative-p and a default character; define-quantity accepts :non-negative-p (which defaults the character to :absolute) and :character, and components inherit both. An unstated character falls to the definition's default, and every quantity in luvcraft/quantities.lisp is unannotated, so every existing specification is a difference exactly as before.
• additive-pair implements the three-way table; product-character makes products and quotients absolute only when every factor is; a bare number preserves the other operand's character; interpret permits the one deliberate crossing, difference to absolute, and no other. Negating an absolute signals :cannot-negate-amount: luv chose the error branch of the source's open question so demotion is a visible mark.
• arithmetic/tests.lisp gained six executable claims covering the definition defaults and the historical :affine-p spelling, cone addition and subtraction, point asymmetries, the multiplicative table, negation, and interpretation-as-promotion. The full fresh-process suite passes (18 arithmetic, 4 language, 5 lisp, 13 core, 31 spir-v, 34 luvcraft), and strict parinfer is clean.
• The language and shader frontends pass :affine-p and the new :character keyword only when stated, so definitions can supply defaults; a declared-character shim keeps every existing source form valid. make shader-validate in a fresh SBCL regenerated all seven production modules byte-identical to their pre-change hashes with spirv-val passing, and make smoke at HEAD gives MD5 edc597168a3ec79a04c6d2af53c5b1a5 both with and without the change (the earlier recorded 226c4f… predates the shadow commits and was stale).

Done when: satisfied — the algebra is in place and inert for the current vocabulary. Annotating luvcraft's amounts, which changes what production materials mean, is #9ZK7Q7.

Mentioned in: Three affine characters: point, absolute, difference, Constraints are marks the author places, not costs the compiler hides, Declare luvcraft's amounts absolute and non-negative

DONE Declare luvcraft's amounts absolute and non-negative #9ZK7Q7

Intent: with the character algebra inert-by-default (#SYUACW), make the block-world vocabulary state its truth: :opacity, :ambient-occlusion, :sky-light-level, :block-light-level, :material-emission, :fog-amount, :day-factor, :linear-rgb, :view-distance, :world-distance, and :shadow-filter-radius are non-negative absolutes; :world-position, :shadow-uv, :texture-uv, :shadow-depth are points by definition rather than by per-site :affine-p t.

Evidence:

• world-position, shadow-uv, texture-uv, shadow-depth, and clip-coordinate are points at their definitions. The listed proportions, colour signals, distances, and filter radius are definition-level non-negative absolutes. Production slots, packed layouts, constants, and shader declarations now omit redundant character spellings; only real differences such as shadow texel size and receiver bias override a default.
• Compiling the stricter production graph exposed rather than concealed four distinctions: homogeneous clip XYZ/W is a heterogeneous representation; clip coordinates must cross the chosen zero origin before scaling; shadow texel offsets and depth corrections are differences; and clamped blocker separation is explicitly promoted from a signed depth difference to an absolute amount. The arithmetic test fixtures also had to stop borrowing shadow-depth while silently assuming its old difference default.
• production-points-and-amounts-reject-invalid-arithmetic proves that negating opacity reports cannot-negate-amount and adding two world-x-position points reports cannot-add-points. Both shader errors retain the exact offending source form. The production quantity and shadow tests inspect the inherited characters and deliberate overrides.
• A detached worktree at 2bd3dfe supplied the baseline. All seven block-world SPIR-V modules are byte-identical after the migration and pass spirv-val; in particular the fragment hash remains da53933e… and the sky vertex hash 2bff3dd9…. make smoke still produces edc597168a3ec79a04c6d2af53c5b1a5.

Done when: satisfied. The vocabulary owns the defaults, production materials compile under the stricter algebra without codegen drift, and invalid point and amount arithmetic has source-level regression tests.

Mentioned in: Generalize affine-p to a three-valued character, Review the exercised quantity architecture, Give the remaining crosshair colour ABI meaning, A staged concretization

DONE Declare quantities on Lisp storage #FLRFU8

Intent: let CLOS slots and defstruct slots state quantity meaning beside their ordinary Common Lisp :type, using the declaration protocol in #OXBSAY. Use the MOP where a CLOS class definition genuinely carries the metadata, but do not make it the only representation of the schema.

Evidence to gather:

• One narrow metaclass with custom direct and effective slot definitions, exact inheritance rules, and live redefinition visible through ordinary MOP inspection.
• One thin structure definer which removes semantic options before expanding to an ordinary defstruct and publishes the same declaration protocol.
• Readable source declarations on block-world-player and sky-frame-parameters, with vec3 and scalar representations unchanged.
• Tests that inspect both definitions, reject conflicting inherited meaning, and show that construction and access still use raw values without quantity wrappers or per-access semantic dispatch.

Result:

• quantity-class uses custom direct and effective slot definitions only for annotated slots. It retains :quantity beside the ordinary MOP :type, propagates equal declarations through inheritance, permits independent Lisp type refinement, and reports contradictory inherited quantities when CLOS computes the effective slot. Redefining a class replaces the visible declaration in the ordinary live MOP.
• define-quantity-struct removes :quantity before emitting an ordinary defstruct. One replaceable EQL method publishes the structure schema, so reevaluation does not leave obsolete per-slot methods behind. Both frontends implement the declaration protocol from #OXBSAY.
• block-world-player now states world position, velocity, body dimensions, speeds, and accelerations beside its unchanged vec3 and double-float representations. sky-frame-parameters similarly states its evaluated direction, colour, angle, exposure, and fog meanings beside the same defstruct layout and accessors.
• Five focused record tests cover MOP inspection, inheritance, live redefinition, semantic conflict, and raw structure access. Two luvcraft tests inspect the real records and construct ordinary raw values. A cold durable image loads the changed metaclass definition, and all 44 luvcraft tests pass.

Done when: satisfied. #GZ53LD now connects these declarations to checked CPU arithmetic at an explicit boundary.

DONE Check storage declarations against Lisp arithmetic #GZ53LD

Intent: make a declared CLOS or structure field usable as an input or output of one checked arithmetic definition without wrapping each runtime value. The boundary should compare the stored representation and quantity declaration with the arithmetic parameter once, choose the existing Lisp realization, and then call ordinary compiled code over the raw vec3 or scalar.

Evidence to gather:

• One small compatibility judgment which distinguishes representation failure from quantity failure and preserves useful source provenance from both sides.
• One real block-world-player calculation, likely integration of velocity over a duration into position, whose storage declarations supply the arithmetic contract rather than restating it in adapter code.
• A deliberately mismatched slot or parameter rejected before the numerical function runs, while the successful path passes the original raw objects and performs no per-component semantic dispatch.
• Live and cold tests showing that the boundary composes with the Lisp compiler completed in #FTQEQD and leaves the shader realization independent.

Result:

• ensure-declarations-compatible compares an actual storage declaration with a realization ABI. Quantity specifications and layouts must agree exactly; a concrete Common Lisp representation must be a known subtype of the expected representation. Its condition retains both source forms and distinguishes semantic from representation failure.
• lisp-arithmetic-realization joins one backend-neutral checked definition to explicit parameter and result representation types. Binding it to storage performs the compatibility checks once and returns the already compiled raw Lisp function. No quantity objects travel through that function.
• The numerical Lisp protocol now admits representation extensions. arithmetic/lisp/vec3.lisp owns the transparent CPU vec3 and implements its componentwise binary operations, dot, and normalization methods as a representation extension. The Lisp arithmetic protocol does not name the type, and neither it nor the representation depends on the block world.
• %predict-world-position derives displacement from world velocity and frame duration, explicitly interprets the derived vector as a world-position difference, and adds it lawfully to a position point. Its vec3 realization is bound to block-world-player's actual position and velocity slots plus a declared double-float duration boundary. The resulting predict-player-position passes the raw slot objects to compiled arithmetic; tests prove the value, input identity, and rejection of velocity substituted for position before numerical execution.
• A cold image passes 21 core arithmetic, 6 Lisp realization, and 44 luvcraft tests. The present Lisp realization still chooses representation methods at each arithmetic operation, though never per component and never for semantic checking. Whether real kernels warrant representation-specialized lowering is deliberately left for the exercised-design review rather than assumed.

Done when: satisfied. #AVRNHW now broadens the declarations beyond the first player and sky records before that review.

Mentioned in: Declare quantities on Lisp storage

DONE Audit quantity-bearing Lisp storage #AVRNHW

Intent: inventory luvcraft's classes, structures, arrays, constants, and function boundaries which carry physical or domain quantities, then migrate the semantic owners in coherent groups. The audit must preserve distinctions between continuous quantities, categorical voxel coordinates, counts, IDs, and packed representation lanes; comprehensiveness does not mean attaching a unit to every number.

Evidence to gather:

• A source-led inventory of remaining unannotated quantity-bearing storage and APIs, grouped by simulation, camera, sky, lighting, meshing/render ABI, streaming, and measurement rather than one undifferentiated grep list.
• Declarations on the next coherent real owners, with exact quantity names and point/absolute/difference character where the code already establishes it.
• Checked CPU arithmetic at boundaries where it improves the code's semantic vocabulary; ordinary direct Lisp remains where a compiled definition would merely obscure a small local calculation.
• Focused tests and pushed checkpoints for each group, plus a running list of ambiguous values that require a domain decision instead of a guessed unit.

Done when: every quantity-bearing luvcraft owner is either declared, mapped to an explicit boundary, or listed with a concrete unresolved semantic question; the migration remains cold-loadable and the full suite passes.

Audit so far:

• Camera position and angles, sky-clock state and keyframes, material lighting facts, and frame-performance durations now declare their semantic quantities. Timing stages retain distinct quantity names even though they all have the duration dimension: simulation time is not presentation time.
• Voxel, chunk, pixel, and draw extents remain deliberately unannotated where they are categorical indices or counts rather than continuous physical measures. The raw 0--15 sky/block propagation levels likewise remain distinct from the normalized light proportions sent to the GPU.
• The voxel-space boundary is now explicit. :cell is a dimensionless but non-identity unit owned by LUVCRAFT.WORLD.QUANTITIES: it cannot silently compare equal to :one or :metre. Continuous world/player/shader positions are measured in cells, cell-extent is a :voxel-cell-extent vector measured in metres per cell, and ray hits carry :ray-distance in cells. The application quantity system depends on that foundational vocabulary rather than defining world meaning above its owner.
• Exercising this boundary corrected the first real design mistake in the migration: the initial player, camera, fog, and shader declarations called lattice values metres because the default cells happen to be one metre. Their representations and numerical behavior are unchanged; only the false equivalence was removed.
• Dense block, sky-light, and block-light columns now have ordinary voxel field definitions (#SIYGXO). Raw u8 sky and block propagation levels carry distinct quantity specifications while normalized GPU light proportions retain their earlier meanings. Field definition identities travel with live columns, solver-atlas copies, and immutable worker snapshots without wrapping their lanes. The interleaved block-mesh vertex buffer remains a heterogeneous repeated product rather than one scalar field. The lighting work item likewise has one level representation whose sky or block meaning comes from the owning queue. The queue now retains that exact field definition (#K2V9RD), rather than falsely annotating the raw slot in isolation. Ordinary function parameters remain an explicit frontend question rather than being forced into record declarations.
• Session state now distinguishes the monotonic frame-clock point from the accumulated physics duration, and production results declare their elapsed duration. Lighting state now likewise declares its most recent reconciliation duration, while its counters remain counts. These calculations remain ordinary direct Lisp: record metadata should not be used as a pretext for wrapping a short subtraction when no checked arithmetic boundary needs it.
• Stable quantity-bearing constants now use define-quantity-constant. The fixed physics step, collision clearance, shadow extents and depth biases, and shadow filter radii remain ordinary unwrapped numbers while publishing the same represented-value declarations as storage and arithmetic parameters. Structural counts such as shadow-map resolution, mesh stride, vertex count, and format version remain ordinary constants.

The interleaved block-mesh vertex vector now carries a repeated 12-lane product declaration (#Q7M4PF), checked against the live block-surface vertex shader contract. Context-dependent removal work now has an explicit semantic owner (#K2V9RD). The fixed frame uniform now has an independently stated CPU product checked against the shader's parsed member quantities (#F8U2LA). The remaining fullscreen and overlay vertex products are similarly declared and checked (#N6S2CX). The completed function-boundary audit is #J4V8QM: it found no consumer for a second metadata-only function signature system.

Mentioned in: Check storage declarations against Lisp arithmetic

DONE Give luvcraft quantities backend-neutral ownership #BRYSBI

Intent: let CPU code name world position, view distance, direction, colour, fog, and related luvcraft quantities without loading their definitions as a side effect of the shader system.

Evidence:

• The open quantity protocols themselves live in :luv/arithmetic, while the vocabulary previously lived at the head of luvcraft/shaders.lisp in the LUV.SPIR-V package. The names are domain meanings used at simulation and ABI boundaries, not properties of SPIR-V.
• luvcraft/quantities.lisp now publishes the unchanged kind and quantity definitions from the LUVCRAFT.QUANTITIES package. They are loaded by the :luvcraft owner after its renderer-independent :luvcraft/world model.
• A fresh SBCL image loaded the quantity files through :luvcraft and resolved :world-position as a length quantity. Full tests, generated-module validation, and the smoke render pass.

Done when: luvcraft quantities are owned outside LUV.SPIR-V; the application and shader packages share them explicitly; focused and project tests retain their behavior.

DONE Move portable operator semantics below shaders #ODID1K

Intent: make the semantic contracts of ordinary numerical operations available to every arithmetic client before extracting the expression frontend.

Evidence:

• + - * / dot min max already derived quantity specifications in arithmetic/semantics.lisp, while clamp, step, mix, smoothstep, normalize, and expt added methods to that same generic from hal/shader/language.lisp. Their contracts did not mention textures, stages, SPIR-V, or another shader-only concern.
• The portable methods and non-CL operator symbols now belong to LUV.ARITHMETIC. LUV.SPIR-V imports and re-exports those exact symbol identities, retaining its established source vocabulary without owning the semantic rules. Live package reload removes the obsolete home symbols before importing their common identities.
• Arithmetic tests exercise all six moved contracts without loading shaders; shader tests assert the common/SPIR-V symbol identities. Strict Parinfer, full tests, and spirv-val pass. The five tracked production shader hashes remain byte-identical, and the smoke render completes at MD5 226c4ffdd4515837d5c5a2d9fc415fa4.
• A forced reload in the durable SLY image replaced the package definitions cleanly and reported EQ identity for all six common/SPIR-V operator names.

Done when: portable operator symbols and quantity-derivation methods are owned below LUV.SPIR-V; arithmetic tests exercise them directly; shader source keeps the same symbol identity and diagnostics; generated shader modules are unchanged.

DONE Extract a compiled arithmetic frontend #VIZMU6

Intent: make one inspectable definition and expression vocabulary usable by both CPU and shader realizations while retaining the shader workbench's source provenance.

Evidence:

• The new :luv/arithmetic/language system depends only on :luv/arithmetic. arithmetic/language/frontend.lisp owns inspectable parameters, lexical bindings, literals, references, calls, quantity boundaries, unit conversions, one-expression function definitions, source reconstruction, and the EQL-specialized operator/parser protocols.
• Common parsing checks quantity contracts while retaining source numeric representation: its tests build a fog-shaped let* graph, reject addition across different quantity spaces, expose an exact kilometre-to-metre conversion factor, and retain a double-float literal rather than coercing it to a shader type.
• Shader expressions now specialize these common nodes while adding shader types and lowering concerns. Existing shader accessors delegate to the common slots and traversal protocol, so current tools retain their public surface. Shader calls remain target-specific typed realizations; stages, interfaces, texture calls, maps, output statements, and SPIR-V provenance remain shader-owned.
• The source words quantity, assume-quantity, interpret, representation, and convert-unit now have their symbol identity in the common language package and are imported and re-exported by LUV.SPIR-V. Shader tests prove both the identity and that production shader calls are also common arithmetic calls with the same reconstructed form.
• A fresh image loads :luv/arithmetic/language without creating the LUV.SPIR-V package. Focused common-language and shader suites pass after a forced live reload, and make test passes with all seven production shader modules byte-identical to the preceding commit. The smoke render remains MD5 226c4ffdd4515837d5c5a2d9fc415fa4.

Done when: a backend-neutral system owns arithmetic definition and base expression objects, one-expression functions and lexical let*, quantity checking, and source reconstruction; the shader frontend extends or consumes that protocol rather than duplicating it; existing shader graphs remain inspectable and lower identically.

Mentioned in: One arithmetic medium, many clients

DONE Compile checked arithmetic to Lisp #FTQEQD

Intent: execute arithmetic definitions on the CPU over ordinary Lisp numbers and vectors after checking their semantic contracts once.

Evidence:

• The separate :luv/arithmetic/lisp system depends only on the common arithmetic language. arithmetic/lisp/compiler.lisp lowers a checked definition to an ordinary lambda and then uses COMPILE; the target function receives and returns ordinary numbers and vectors.
• define-lisp-arithmetic-function is a thin definition form over the common source protocol. It publishes the same inspectable EQL-method definition as define-arithmetic-function and emits a normal DEFUN from the checked lowering, so CPU callers use it like ordinary Lisp code.
• Quantity construction, assumption, interpretation, and representation are compile-time-only boundaries in the emitted lambda. An explicit unit conversion becomes its exact numeric scale. Runtime numerical helpers operate over scalars or vector storage without quantity wrappers or per-element CLOS dispatch.
• Focused tests execute the fog-shaped let* directly as a compiled double-float function, add and dot ordinary vectors, translate an affine point by a difference, lower kilometres to metres as an exact factor of 1000, and reject both point-plus-point and distance-plus-height before Lisp compilation.
• A fresh Lisp image loads :luv/arithmetic/lisp and runs a standalone CPU definition without loading the SPIR-V package. Live SLY redefinition replaces both the semantic definition and ordinary function. make test passes with all seven generated shader module hashes unchanged, and make smoke retains MD5 226c4ffdd4515837d5c5a2d9fc415fa4.

Done when: a Lisp realization lowers a checked definition to a compiled function without runtime quantity wrappers; tests prove numerical execution, compile-time rejection of a dimensional mistake, affine arithmetic, and an explicit unit conversion.

Mentioned in: Check storage declarations against Lisp arithmetic, One arithmetic medium, many clients, Quantity-carrying shader types, Structural shader-type identity

DONE Share one production computation between CPU and GPU #D1R2NK

Intent: make definition sharing answer a real engine question rather than only demonstrate two toy evaluators.

Evidence: fog shaping is a small scalar candidate; the :world-to-light map is a richer candidate already used by production shaders and useful to CPU tests and tools. The latter should follow the semantic-map split and the homogeneous-projection composition work in #ZYCSYZ rather than forcing its current shader representation into the common layer. The field/kernel seam in #ADR040 supplies another production-shaped test: light-level decoding or a named light-response law can connect one semantic field to CPU tooling and GPU presentation without asking the arithmetic graph to own light propagation.

The first shared law is luvcraft.arithmetic:fog-amount-at-view-distance. It owns the production near/far clamp and quadratic curve as one backend-neutral arithmetic definition over :view-distance, returning :fog-amount. The block-world vertex shader now calls that definition instead of spelling out the formula, and shader lowering inlines it into the same target-appropriate scalar operations.

The CPU realization in luvcraft/sky.lisp compiles the same definition to an ordinary single-float function. Definition-time binding checks its ABI against the actual fog-near and fog-far quantity slots on sky-frame-parameters; sky-fog-amount-at-distance then answers the engine question with raw Lisp floats and no runtime quantity wrappers. Tests find the named call in the production shader graph, execute the CPU curve below, between, and beyond its bounds, and reject substituting a :fog-amount slot where the shared :view-distance contract requires distance.

The definition lives in the LUVCRAFT.ARITHMETIC package rather than the quantity vocabulary or either backend: quantities name meaning, while arithmetic graphs own numerical laws.

Done when: satisfied by the named fog law and its two checked realizations. The richer :world-to-light composition subsequently became #ZYCSYZ without forcing homogeneous GPU representation into the common arithmetic layer.

Mentioned in: Review the exercised quantity architecture, One arithmetic medium, many clients, Structural shader-type identity, A staged concretization

IDEA Lower checked domains to native SIMD kernels #VKLLPR

Intent: eventually let a field or simulation phase select a scalar or SB-SIMD realization of the same semantic operation once per dense kernel.

Evidence: #B5L7VG and the native SIMD study describe the representation seam, and #LDP5UR now supplies generated quantity-aware SoA storage. The first executable probe uses with-columnar-buffer-storage to borrow two single-float position lanes with their retained row declaration. Separate scalar and SB-SIMD kernels compute the same squared-position reduction, with AVX/SSE selected once on x86-64 and NEON available on arm64; an odd row count exercises the scalar tail.

On SBCL 2.6.6 x86-64 with AVX2 available, five warmed pairs of 100 reductions over 1,048,579 rows took 0.060--0.061 seconds scalar and 0.008--0.009 seconds through eight-wide AVX, with zero steady-state consing. Disassembly shows two VMOVUPS loads, two VMULPS operations, and pack additions in the loop. This is real native execution over generated columnar lanes, not autovectorization.

The probe also exposed the semantic issue a real kernel must settle: the scalar result was 4.1941624e9 while the pack reduction was 4.1923423e9. Both are deterministic, but SIMD reassociation changes a long single-float sum. A future shared arithmetic kernel needs an explicit reduction-order or error contract rather than assuming the scalar oracle will be bit-identical. #IUTMUY records why SB-SEQUENCE is useful around this storage but not as its hot traversal protocol.

Done when: promoted when a real domain computation, rather than this storage oracle, owns a stable scalar definition, reduction contract, and columnar layout worth accelerating.

Mentioned in: A columnar buffer is not one hot sequence, One arithmetic medium, many clients, A staged concretization

DONE Prove semantic arithmetic in the shadow graph #9P358P

Intent: let one real shader calculation test whether dimensions, named quantity spaces, tensor order, and affine points belong in a reusable arithmetic graph. Keep SPIR-V resources and lowering shader-specific; keep semantic arithmetic in a backend-neutral layer that a later scalar or SIMD kernel could also consume.

Evidence:

• arithmetic/semantics.lisp now represents canonical symbolic dimensions and inspectable quantity specifications. EQL methods on ordinary arithmetic symbols derive addition, subtraction, products, quotients, and dot products.
• Shader inputs, outputs, and uniform members can opt into :quantity, :dimension, :unit, and :affine-p without changing their shader-type or SPIR-V representation. Arithmetic expressions retain the derived specification.
• Once an annotation enters a shader expression, semantic derivation is total: an unannotated operand or an operator without a quantity rule is a parse-time error. Fully unannotated shader graphs remain valid while the vocabulary is grown deliberately.
• min and max require exactly compatible specifications. Unit expressions compose through products and quotients, but there is no implicit common-unit selection: :metre and :kilometre remain different until source performs an explicit conversion.
• quantity constructs typed constants, assume-quantity marks otherwise raw boundaries, and interpret names only a compatible checked result. All three alias their operand during lowering. interpret rejects raw values, unit changes, affine changes, and semantic relabelling.
• Shader-specific EQL methods define the demonstrated semantic vocabulary: sample and sample-compare boundaries, vector constructors, clamp, step, mix, and smoothstep. Once checking begins, an absent rule is an error rather than a reason to discard semantic information.
• arithmetic/tests.lisp rejects equal-dimensional but differently named quantities, mismatched exact units, and illegal affine operations. hal/shader/tests.lisp proves shadow-depth subtraction and compatible max, rejects point-plus-point, depth-plus-length, metre-plus-kilometre, missing annotations, and unsupported semantic operators, and produces byte-identical SPIR-V with and without semantic annotations.
• A clean mp-units reference checkout at commit 20cedd5 shows the useful separation between quantity specification and unit reference. Its arithmetic finds a common reference and converts operands; this experiment intentionally adopts the separation but requires exact units instead of implicit conversion.
• The production block fragment graph now distinguishes shadow UV points and offsets, shadow-depth points and differences, cell-valued world spans, gradients, filter radii, light controls, and linear colour. Strict checking continues from the shadow result through lighting and fog to the final RGBA.
• The production fragment module remains byte-for-byte identical to the module from before those annotations (SHA-256 da53933e77ce1a1f6123be4c5884aef43b0f28ddff849e12fe8125bc354bc494). Keeping receiver-depth at its original demand point also demonstrated that source-order bindings are part of deterministic code generation even when semantic interpretation itself emits no instruction.
• The shader workbench shows representation type beside semantic meaning for interface values, packed uniform members, bindings, and selected expressions; construction, assumption, interpretation, and packed component layouts stay visible and selectable in the expression tree.

Outcome: the production proof covers coherent named spaces, tensor order, affine points, exact units, source-facing failures, unchanged SPIR-V, and live presentation. Numerical unit conversion was deliberately not smuggled into interpret; the separate operation was subsequently completed in #7MHTYL.

Mentioned in: Expressions, declarations, and bindings are objects, Quantity-carrying shader types

DONE Give GPU components first-class quantity meaning #SQR8KR

Intent: make homogeneous vector quantities and heterogeneous packed GPU tuples different semantic structures. Let a whole vector already carry quantity meaning, let exact swizzles recover explicitly declared component meanings, and make every undeclared projection or packed-whole arithmetic operation fail at parse time.

Evidence:

• arithmetic/semantics.lisp defines backend-neutral quantity-layout and quantity-projection objects; inspectable quantity definitions own the ordered component names of homogeneous vectors.
• hal/shader/language.lisp carries layouts through interface variables, uniform members, references, and texture samples. swizzle accepts only an exact declared layout projection or a lawful homogeneous projection.
• The production block material declares uv-shade.xy as texture UV and z as ambient occlusion; three independent light lanes; colour/diagnostic and shadow-control uniform packs; RGB/alpha atlas samples; and scalar depth samples. The sky ray crosses its vertex/fragment interface as one :world-direction vector whose y component has its own quantity name.
• hal/shader/tests.lisp proves heterogeneous packed projections, rejects yz and whole-packed arithmetic, proves named homogeneous axes and texture sample channel layouts, distinguishes quantity, assume-quantity, interpret, and representation, and checks their zero-codegen behavior.
• The shader workbench presents packed lane maps and the four kinds of semantic boundary rather than flattening them into an undifferentiated annotation.

Done when: achieved. Component meaning is declared at the value or resource boundary, projection is exact and checked, production shaders exercise both homogeneous and heterogeneous cases, and valid semantics remain representation- and codegen-neutral.

Mentioned in: Expressions, declarations, and bindings are objects, The frame uniform was an unlabeled quantity ledger, Quantity-carrying shader types

DONE Make numerical unit conversion explicit #7MHTYL

Intent: add a visible arithmetic operation for conversions such as kilometres to metres without weakening exact-unit checking or turning interpret into a scale-changing cast. Learn from mp-units' quantity/reference separation while keeping conversion policy small and inspectable.

Evidence:

• arithmetic/semantics.lisp now defines inspectable unit-definition objects behind an open unit-definition-for EQL protocol. The initial vocabulary included :one, :metre, :kilometre, :second, and :percent with dimensions, canonical bases, and scales; #V3TSZA subsequently made their admissible quantity kinds explicit and added more coherent ISQ/SI units. Unknown unit symbols are errors.
• A quantity specification derives its dimension from a declared unit and rejects a contradictory explicit dimension. Compound expressions retain exact named units; unit-conversion-factor separately proves a shared basis and computes source magnitude divided by target magnitude.
• convert-quantity-specification-unit preserves name, physical dimension, tensor order, and affine character. It cannot perform semantic relabelling.
• hal/shader/language.lisp represents convert-unit as a first-class typed expression with source provenance. A non-unity factor lowers to an explicit scalar or vector multiply; a unity factor remains a visible semantic node while safely aliasing its operand.
• The shader workbench renders the conversion operand, target specification, and scale factor as a selectable expression rather than hiding the change in its generated arithmetic.
• Arithmetic tests prove kilometre/metre and percent/one conversion, dimension inference, mismatch rejection, and undefined-unit failure. Shader tests prove that 50 percent opacity becomes 1/2 one opacity through an emitted F-MUL, and reject raw, dimension-changing, and unknown- unit conversions.
• The production shader binaries and their Vulkan validation remain unchanged; conversion is available without introducing implicit conversion into any existing operation.

Done when: achieved. Unit changes are numerical operations distinct from interpretation, and dimension-one units exercise the same mechanism as physical units.

Mentioned in: Calculation derives; interpretation names, Prove semantic arithmetic in the shadow graph

DONE Constrain units to semantic quantity kinds #V3TSZA

Intent: add the mp-units distinction between universally scaled units such as one and percent and kind-specific units such as radian, steradian, or bit. Let semantic quantity definitions form a small open hierarchy without weakening the current exact-name safety.

Evidence: #RK56VG and Moppe's live quantity catalogue show why equal dimension does not imply either equal meaning or universal unit admissibility. mp-units uses dimension-one subkinds for angles and storage while retaining one and its scaled forms across the hierarchy.

• arithmetic/semantics.lisp now defines inspectable quantity-kind-definition and quantity-definition objects behind open EQL protocols. Kinds form a same-dimension parent hierarchy; quantity specifications expose their kind without replacing the exact quantity name used by arithmetic.
• Every named unit declares its admissible root kind. The seed vocabulary now includes one, percent, per-mille, parts per million, metre, kilometre, second, hertz, radian, and steradian. Radian and steradian have the same physical dimension as one but different semantic constraints.
• Named construction and conversion require a declared quantity definition whenever a named unit imposes a kind. A missing definition and a dimensionally equal but inadmissible unit are hard errors; compound derived units continue to be checked dimensionally without inventing a result kind.
• The production shader vocabulary classifies normalized texture/shadow coordinates, affine normalized depth, unit directions, proportions, relative linear-colour signals, controls, gradients, sample counts, and world distance. Their declarations now say :unit :one or :unit :metre explicitly.
• The lane called sun angular width is deliberately a normalized :sun-disc-coordinate rather than an angle: its stored value is subtracted from a cosine alignment near one. Giving it radians would make the source sound more physical while describing the actual representation less truly.
• Arithmetic tests accept an angle in radians and an opacity-like proportion in percent/one, reject proportion-in-radians, angle-in-steradians, and units on unregistered quantities. Shader tests exercise the same failures at the source-language boundary and inspect production quantity kinds.
• The shader workbench now includes the semantic kind in its quantity label, keeping name, kind, dimension, unit, tensor order, and affine character separately visible.
• make test passes strict Parinfer checks, all arithmetic/shader/project suites, generated-module validation, and make smoke renders successfully. The production fragment remains byte-identical at SHA-256 da53933e77ce1a1f6123be4c5884aef43b0f28ddff849e12fe8125bc354bc494.

Done when: achieved. Unit definitions declare an admissible quantity kind; quantity construction and conversion reject a dimensionally equal but semantically invalid unit; one and percent continue to express named dimension-one quantities; radians express angles but not opacity; and the design leaves room for symbolic magnitudes such as pi-over-180 without approximating them during semantic checking.

Mentioned in: Make numerical unit conversion explicit

DONE Carry semantic units through the vertex and camera ABI #S00PRF

Intent: extend the production proof from the heavily annotated fragment and sky calculations into the block vertex boundary. World and camera positions should be cell-valued affine vectors; their subtraction should be a cell difference; camera basis vectors should be unit directions; fog near/far should be cell distances; and normalized mesh lanes should cross the vertex/fragment interface with the meanings they already have downstream.

Evidence:

• luvcraft/shaders.lisp now declares camera and world positions as affine :world-position vectors in cells, the three camera basis lanes as unit :world-direction vectors, projection scales in one, and fog near/far and projection depth offset as cell-valued :view-distance values.
• Point subtraction derives a non-affine cell vector; its forward projection is interpreted as view distance, while fog subtraction and division derive a dimensionless progress value before interpretation as :fog-amount.
• The mesh ABI publishes texture UV plus ambient occlusion, unit normal, and three distinct light lanes on both sides of the vertex/fragment interface. In this iteration shadow UV and depth acquired their normalized meanings at the opaque shadow-transform result; #U0AHTQ subsequently replaced that assumption with a checked map. The shadow and sky vertex stages share the semantic frame declarations rather than reintroducing direction meaning downstream.
• #F83KGZ records the explicit representation boundary used where a semantic metre point entered the then-raw homogeneous shadow rows. It was visible in the expression graph and shader workbench, required a semantic operand, and had no codegen effect; #U0AHTQ records its semantic replacement.
• Shader tests inspect the affine/non-affine transition, exact metre units, interface layouts, representation boundary, and the rejection of a representative metre/one mix-up. The focused suite passes all 28 tests.
• Vulkan validation passes, and all five generated scene binaries remain byte-identical: block vertex 9c99780b969b33eb242976c943463449b2cce4b66f779674a291fc3a4f2aeb34, sky vertex 2bff3dd9c5b4ffe74746a324b05868b12f866749b7cc5670ae47d39a53925fac, shadow vertex 4402a20bc62ef9289244ec0b52d2cd32f644147938d372eda308021ce49c300a, block fragment da53933e77ce1a1f6123be4c5884aef43b0f28ddff849e12fe8125bc354bc494, and sky fragment 2d7085ebfbe0c35e18cd96deb25369a28cbec391a55589ae747ff7ef8a0d9c48.
• make test passes strict Parinfer, the complete project suites, and generated module validation; make smoke renders the block world successfully.

Done when: achieved. Vertex camera arithmetic is checked in metres, dimensionless fog is derived rather than asserted, normalized mesh meanings cross the stage interface, opaque representation boundaries are explicit, a metre/one mix-up is rejected, and the emitted SPIR-V is unchanged.

Mentioned in: The frame uniform was an unlabeled quantity ledger, Quantity-carrying shader types

DONE Introduce the world-to-light sampling map #U0AHTQ

Intent: replace the most consequential remaining raw arithmetic island with a first-class map whose domain, codomain, affine-point requirement, packed result, and projective coordinate remap are checked independently of its four-row GPU representation.

Evidence:

• hal/shader/language.lisp now provides inspectable shader-map-definition objects behind an open name protocol, a projective definition with coordinate scale/offset, a project-point expression, and lowering specialized on the map definition class.
• The first block-vertex version applied :world-to-shadow directly to an affine :world-position in cells. Its virtual packed result projected :shadow-uv and :shadow-depth with their affine normalized meanings; the prior representation and two assume-quantity nodes left this path. The composition was subsequently split and renamed by #ZYCSYZ.
• Undefined maps, raw or wrong-domain points, the wrong number of rows, and semantically annotated rows are source-language errors. Missing map semantics therefore cannot silently collapse to raw arithmetic.
• The virtual product lowers once and exact swizzles reuse its component IDs; it adds no intermediate vector. Vulkan validation passes and the block vertex binary remains byte-identical at SHA-256 9c99780b969b33eb242976c943463449b2cce4b66f779674a291fc3a4f2aeb34.
• The shader workbench renders the map application as its own selectable expression, including the named map, semantic point, and represented rows. Shader tests inspect its domain, packed result, affine character, virtual materialization policy, raw rows, and failure contracts.

Done when: achieved. A real production matrix application is a checked semantic map, point versus raw/direction misuse is rejected, projected fields arrive with meaning rather than assumptions, tools can inspect the map object, and emitted GPU code is unchanged.

Mentioned in: Carry semantic units through the vertex and camera ABI

DONE Separate homogeneous projection from shadow sampling #ZYCSYZ

Intent: let one semantic world-to-light projective map serve both production uses of the four shadow rows. The shadow vertex stage needs the homogeneous clip result directly, while the block vertex stage additionally divides and remaps it into shadow sampling coordinates. Those should be named operations over one map rather than two unrelated arithmetic spellings.

The map is now :world-to-light. project-point checks its affine :world-position domain and four raw rows, then denotes the homogeneous light-space vec4. project-sample accepts only such an application and projects its declared virtual :shadow-uv plus :shadow-depth sample product. The map definition names the homogeneous and sample representation types and owns the sampling layout and coordinate remap separately.

The shadow vertex stage sends the homogeneous application directly to clip position. The block vertex stage nests the same application under project-sample and selects exact sample fields; no intermediate vec3 or vec4 is materialized there. The McCLIM workbench presents both nodes. Tests inspect their relationship, require the same map definition in both production stages, reject raw/direction points and sampling projection of a raw clip value, and retain source provenance.

Done when: satisfied. Both Vulkan modules validate and remain byte-identical: block vertex SHA-256 9c99780b969b33eb242976c943463449b2cce4b66f779674a291fc3a4f2aeb34; shadow vertex SHA-256 4402a20bc62ef9289244ec0b52d2cd32f644147938d372eda308021ce49c300a. Direct MSL lowering mirrors the same composition and both production Metal sources compile.

Mentioned in: Review the exercised quantity architecture, Share one production computation between CPU and GPU, Introduce the world-to-light sampling map

DONE Give the remaining crosshair colour ABI meaning #NXA19H

Intent: finish the first production-shader audit at the small crosshair pipeline. Its literal vertex module carries an RGB ink tuple into the mathematical fragment method, where that boundary should state linear RGB and the final alpha construction should state opacity and linear RGBA explicitly.

Evidence: the mathematical crosshair vertex and fragment interfaces carry linear-rgb, the fragment constructs its fourth lane from an explicit opacity quantity, and the heterogeneous tuple crosses one visible representation=/=assume-quantity boundary into linear-rgba. The production test inspects all three meanings. The general quantity tests reject colour and proportion mixing, while #9ZK7Q7 adds the production amount failures. Both crosshair modules pass spirv-val and are byte-identical to 2bd3dfe (fragment d89e76bb…, vertex 2577a6d3…).

Done when: satisfied. Every crosshair colour lane has meaning, the packed RGBA boundary is explicit and checked, and lowering is unchanged.

DONE Quantity-carrying shader types #7W7P72

Intent (as first written): extend the shader expression language's inferred types with an optional quantity-specification component, derived by operator methods and named at abstraction and resource boundaries, erased at lowering.

Evidence: this design was realized under other marks before this one was selected. #9P358P proves semantic arithmetic in the production shadow graph; #SQR8KR gives GPU components first-class meaning through quantity layouts; #S00PRF carries units through the vertex and camera ABI; and #FTQEQD shows the specification is erased at lowering on the Lisp side as it is in SPIR-V. The uniform member list now declares lane meanings that host writers and shader readers both see, and production shader modules stayed byte-identical while the checks were added. What this mark's own evidence list still lacks is the sRGB seam, split out below as #NC1YZ4.

Done when: satisfied by the marks above; retained so the design rationale in #TZHN8G and #P2KN1D stays traceable to its realization.

Mentioned in: Logarithmic quantities as affine structure

DONE Give the sRGB atlas seam explicit transfer meaning #NC1YZ4

The original intent correctly found a seam but proposed the wrong type. rgba8-unorm-srgb stores nonlinear RGB bytes; both Metal and Vulkan apply the sRGB transfer when the texture is sampled, so the value entering shader math is already linear. Alpha is ordinary normalized opacity. Labeling that sample encoded-rgb would make the quantity checker contradict the backend.

Transfer encoding is therefore representation metadata, parallel to rather than inside the quantity hierarchy. Texture resources may declare :sample-transfer :srgb-to-linear while their sample component layout says linear-rgb plus opacity. The block atlas does so. The host owns one +block-atlas-texture-format+, texture-format-sample-transfer maps its sRGB format to the same transfer, and session construction checks the actual descriptor format against the shader resource before creating the texture.

Tests inspect the decoded transfer and linear quantities, reject unknown transfers and transfer metadata on non-textures, and reject binding the block shader contract to rgba8-unorm. Sample-transfer metadata is erased from both SPIR-V and MSL lowering; the validated production binaries remain byte-identical.

Done when: satisfied by keeping encoded bytes at the texture representation boundary, declaring the automatic decode, and checking that declaration against the real host format. If luv later performs arithmetic over encoded CPU pixels, that separate client can earn an encoded-colour quantity; the shader sample cannot.

Mentioned in: Review the exercised quantity architecture, Quantity-carrying shader types

TODO Structural shader-type identity #RDI1HA

Intent: make shader-type identity structural — hash-consed composite types mirroring SPIR-V's own type grammar, keywords as parse abbreviations — per #P2KN1D. The CPU-lowering half this mark originally bundled is done: #FTQEQD compiles checked definitions to Lisp, and #D1R2NK is the NEXT mark for a real shared production computation. This mark keeps only the representation-type half.

Evidence to gather:

• register-shader-type still interns flat keywords; :depth-texture-2d remains a distinct name rather than an image-type parameter. Replace the registry with interned structural instances keeping shader-type= eq-cheap.
• New texture flavors (3D, array, cube, multisample) expressible as parameter values without new registry entries, as the Metal path (#DR3V60) will want.

Done when: type identity is the structure, keywords are abbreviations, depth-ness is an image parameter, and existing shader tests and generated module hashes are unchanged.