@photivra/engine 1.5.0 → 2.0.0

package/docs/PSF_FOUNDATION.md

@@ -1,165 +0,0 @@
-# PSF and Pupil Foundation
-
-Release context: **package 1.2.0 candidate / root API 1.2.0**. Subsystem/model versions and dated introduction or measurement records below are independent historical identities; they are not distribution versions. See [developer navigation](DEVELOPERS.md) and [release contract](RELEASE_1_2_0.md).
-
-Photivra has two complementary PSF layers.
-
-The legacy foundation keeps the ideal **geometric defocus-circle** and **circular Airy first-zero** diagnostics separately named and independently testable. The #113 real-lens framework adds explicitly profiled or pupil-derived **combined primary-optical PSFs** without converting those older diagnostics into a synthetic blur score.
-
-## Legacy diagnostics
-
-Use `getPsfFoundationContract()` and `calculatePsfFoundationComponents()` for the established diagnostics and common field/depth/wavelength/pupil context.
-
-The foundation contract is version `0.3.0`.
-
-Implemented diagnostic contributions:
-
-- geometric defocus circle;
-- circular diffraction first-zero diameter.
-
-Implemented framework contributions:
-
-- ideal regular-polygon diffraction density (on-axis, in focus);
-- mechanical pupil clipping / cat-eye PSF shape;
-- field curvature;
-- field-dependent aberration;
-- field-dependent bokeh / signed-defocus response.
-
-Arbitrary curved-blade, off-axis and clipped-pupil diffraction is not inferred by the ideal polygon API.
-
-The legacy component calculator still returns no combined PSF. That is intentional: a combined PSF is available only when an explicit #113 profile or complex pupil supplies the information needed to justify one.
-
-## Ideal polygon diffraction
-
-`calculateIdealPolygonDiffractionPsf()` reuses the regular-polygon geometry and image-plane conventions, but evaluates its continuous Fourier transform analytically rather than rasterizing the pupil into the bounded #113 DFT grid. This avoids a second sampled approximation of the same ideal aperture; #113 still owns arbitrary complex sampled pupils and aberration phase.
-
-Inputs are explicit: equal-area physical pupil diameter, pupil-to-image propagation distance, wavelength and resolved air/vacuum basis, blade count/orientation, and image-plane displacements in micrometres (+X right, +Y up). A nonzero displacement is a location within the **on-axis PSF**, not an off-axis source field position. There is no implicit wavelength conversion or focus-to-propagation-distance conversion.
-
-For unit-circumradius area `A_unit = n sin(2π/n)/2`, the physical radius is `sqrt(A/A_unit)`, with `A = π(D_equal_area/2)²`. This fixes equal area, not equal circumradius/inradius. Under a declared nominal-area convention, a caller may use `D_equal_area = f/N`; that convention is not an inferred real-lens pupil calibration.
-
-For dimensionless pupil coordinates `u`, the independently derived boundary integral follows the divergence theorem:
-
-`F(q) = i/|q|² Σ_edges (qx Δy − qy Δx) exp(−i q·midpoint) sinc(q·edge/2)`.
-
-The phase coordinate is `q = 2π R x/(λ L)`. The center uses the exact area limit. Subtracting each edge's constant term (which sums to zero on a closed contour), a cancellation-safe sinc-minus-one series and `cos(t)−1 = −2 sin²(t/2)` keep near-origin evaluation stable. There is no FFT, pupil rasterization or hidden pupil-grid convergence parameter.
-
-Output gives both `|F/A_unit|²` (unity at center) and continuous intensity density `A |F/A_unit|²/(λ L)²`, converted from 1/mm² to **1/µm²**. Parseval's identity gives unit integral over the infinite image plane. Neither the density nor the peak-normalized intensity is a discrete probability weight. A finite point list is **not** renormalized to sum to one. Renderer quadrature must multiply density by image-plane area, measure support truncation and convergence, and explicitly own any finite-kernel normalization. Throughput stays separate.
-
-Bounds: 3–1024 blades, 1–4096 image points per request, finite positive scales and dimensionless phase radius at most `1e6` (a computational envelope, not a calibrated accuracy claim). Unsupported fields, including aberration/clipping/field inputs, fail closed. Uniform unit amplitude and zero phase are fixed ideal-model assumptions; there is no defocus, curved-blade, field, polarization, sensor, stray-light or polychromatic claim. No quantified physical uncertainty is asserted.
-
-Validation independently checks square sinc-squared response (absolute tolerance `5e-13`), rotated odd/even apertures, direct triangular-pupil quadrature refinement, the equal-area many-blade circular limit (absolute intensity tolerance `1e-7` at the tested points), and finite-support energy integration/refinement. Those tolerances describe test evidence, not universal real-lens accuracy bounds.
-
-Mathematical reference: [Sillitto, Fraunhofer diffraction at straight-edged apertures (1979)](https://doi.org/10.1364/JOSA.69.000765), whose abstract establishes analytical polygon Fourier methods. The implementation and tests are independently authored from Fourier integration, the divergence theorem and Parseval's identity; no third-party implementation, tabulated data or protected exposition is incorporated. AI-assisted draft work still requires substantive human provenance/science review under `PROVENANCE.md` and DCO certification before inclusion.
-
-The circular Airy diagnostic remains separate and unchanged. Do not convolve this diffraction PSF over a #113 kernel that already includes diffraction. This standalone API does not enable an uncomposed production-plan stage or change the POC.
-
-## Sampled real-lens PSFs
-
-`LensSampledPsfProfile` stores full 2D intensity PSFs on an explicit regular calibration/simulation grid.
-
-Profile axes:
-
-- focal length;
-- focus diopters (`0` = #103 optical infinity);
-- f-number;
-- image-plane field X/Y;
-- wavelength;
-- signed image-plane defocus.
-
-Every node declares a unit-energy PSF kernel with physical X/Y sample pitch. All nodes in one interpolated profile must share the same kernel grid geometry.
-
-`resolveLensSampledPsf()` reports either:
-
-- `exact-grid-sample`; or
-- `interpolated`.
-
-No extrapolation is permitted.
-
-The full 2D kernel preserves image-plane +X right / +Y up orientation, allowing off-axis sagittal/tangential/asymmetric structure instead of forcing radial symmetry.
-
-## Field curvature and longitudinal chromatic focus
-
-Each sampled node carries `bestFocusImagePlaneOffsetMicrometers`.
-
-That quantity may vary with:
-
-- field position — field curvature;
-- wavelength — longitudinal/axial chromatic focus;
-- focal/aperture/focus configuration.
-
-It is a focus/PSF quantity. It does not modify geometric distortion, lateral CA, or the selected camera focus-control state.
-
-## Complex pupil / wavefront reference
-
-`LensComplexPupilProfile` represents one explicit primary-optical state as:
-
-- relative pupil amplitude; and
-- optical-path difference in micrometres.
-
-`calculateLensComplexPupilPsf()` performs deterministic scalar Fraunhofer propagation of that complex pupil.
-
-The optional `propagationDistanceMm` explicitly sets the physical image sample pitch `wavelengthMm * propagationDistanceMm / (pupilSampleCount * pupilPitchMm)` per axis. The result returns the resolved distance and whether it was explicit. Omission preserves the existing nominal focal-plane reference using `focalLengthMm`; finite-focus profile metadata alone does not replace that scale. For an owned ideal thin-lens principal-plane fixture, resolve the finite image distance with `calculateThinLensImageDistance()` and pass it explicitly. A real exit-pupil geometry requires its own qualified distance and applicability evidence. Model 1.1.0 adds this input/result binding without changing the legacy kernel values. Pupil schema remains 0.1.0.
-
-This path evaluates diffraction and aberration in one pupil calculation. Do not stack another independent Airy or diffraction blur over its output.
-
-The output intensity PSF is normalized to unit energy.
-
-## Pupil clipping and throughput
-
-PSF energy normalization and optical throughput are separate.
-
-A clipped pupil can change:
-
-1. the pupil/PSF shape; and
-2. the relative amount of transmitted light.
-
-The #113 profiles therefore keep `relativePupilThroughputFactor` separate from the normalized PSF kernel. The throughput factor belongs in the optical-throughput path (including #110 integration) and must be applied exactly once.
-
-The existing illumination-vignetting primitive remains a separate throughput-only approximation; it does not become pupil clipping automatically.
-
-## MTF boundary
-
-MTF magnitude is useful validation evidence, including sagittal/tangential trends.
-
-It does **not** uniquely determine a PSF without phase.
-
-`assessMtfOnlyPsfRenderability()` therefore always blocks unique PSF reconstruction from magnitude-only MTF data while allowing diagnostic use.
-
-## Sensor and stray-light boundaries
-
-V1 lens PSF profiles are `lens-primary-optical-path-only`.
-
-They exclude:
-
-- sensor OLPF;
-- microlens response;
-- CFA/spectral sensor response;
-- sensor crosstalk;
-- sensor sampling;
-- RAW reconstruction/demosaic;
-- sharpening/denoise;
-- ghosting, flare and veiling glare.
-
-A future combined camera-system response must be labeled separately rather than silently stored as a lens PSF.
-
-#114 owns stray light.
-
-## Preview and reference use
-
-The sampled-profile contract can be consumed by both preview and reference paths.
-
-The complex-pupil scalar Fraunhofer evaluator is a deterministic reference calculation. A preview implementation may use a validated approximation, but it must preserve the same profile semantics, field orientation, throughput ownership and limitations.
-
-## Independent pupil sampling pilot
-
-The candidate Print qualification includes `test/print-depth-pupil-convergence.test.ts`. A separately authored factored finite DFT and continuous shifted-complex-pupil overlap integral compare the actual public backend at 25 cycles/mm, 500 nm, focus 5 m, subject distances 2/5/10 m and f/8,16,32. The focused continuous integral also agrees with the analytic ideal circular-pupil transfer. Independent Simpson evaluations at 4,096 and 16,384 intervals differ by less than `1e-11` for this domain.
-
-An unpadded pupil grid can sample intensity too coarsely even when amplitude propagation is numerically correct. Increasing pupil resolution without expanding the zero-padded grid does not necessarily converge to continuous intensity transfer. The historical 9×9 finite reference has absolute transfer errors exceeding 0.14 in the f/32 cases. Those finite reference outputs remain unchanged and are not physical convergence evidence.
-
-The pilot separately varies pupil resolution and padding: padded grids 9/17/33/61 with pupil-radius samples 2/4/8/15. Errors need not decrease monotonically at each finite circular-boundary raster. The final 61×61 grid has absolute transfer error below 0.01 at the tested frequency for all nine combinations. This is a candidate computational criterion informed by the pilot, not a predeclared physical calibration tolerance, quality threshold, all-frequency certificate, support-truncation guarantee for other stimuli, or real-lens validation. The declared finite pupil contract and its bounds remain unchanged. New frequencies, source support, fields, profiles or imaging domains require their own independent evidence.
-
-## No scalar lens quality
-
-Photivra does not produce a universal lens sharpness or bokeh-quality score.
-
-Real optical response remains field-, focus-, aperture-, wavelength-, pupil- and defocus-dependent. Generic equipment tiers may later choose different versioned profiles, but the tier label is not itself an optical algorithm.

package/docs/RAW_FRAME_ENVELOPE.md

@@ -1,56 +0,0 @@
-# Reference RAW frame compatibility
-
-Release context: **package 1.2.0 candidate / root API 1.2.0**. Subsystem/model versions and dated introduction or measurement records below are independent historical identities; they are not distribution versions. See [developer navigation](DEVELOPERS.md) and [release contract](RELEASE_1_2_0.md).
-
-A valid RAW attachment does not establish readiness for reconstruction or paired
-export. The limits below apply to the current browser-safe reference adapters,
-not a typical-camera-resolution production implementation. Count full native
-sites before cropping; a small active area or output view never reduces that
-count for producer/reconstruction admission.
-
-| Boundary | Inclusive budget | Additional conditions |
-| --- | --- | --- |
-| `parseSensorRawFrameInput()` / `createSensorRawFrame()` | 65,536 full native sites | Dense row-major uint16 attachment; single-frame native-effective periodic CFA; explicit one-site binding and consistent codes/flags |
-| `parseSensorRawProducerInput()` / `simulateSensorRawFrame()` | 4,096 full native sites | Complete per-site exposure/charge/readout declarations and existing noise/seed identities; upstream radiometry remains declared |
-| `parseRawFrameReconstructionInput()` / `resolveRawFrameReconstruction()` | 4,096 full native sites | Native in-frame region; at most 64 CFA phases, 16 output channels and 256 contributions per phase profile; complete phase dispatch |
-| `parsePhotographicExportInput()` / `createPhotographicExportPair()` | Inherits the 4,096 full-native-site reconstruction budget | Registered 2×2 RGB Bayer; ordered RGB reconstruction channels; 1:1 oriented crop/output sampling; reconstructed region covers the native final crop |
-| Corrected paired export | Same full-native budget | Reconstruction covers the entire active native area, even when the final output crop is smaller; existing correction support/selection rules still apply |
-| Internal baseline JPEG encoder | 4,096 output pixels | Its independent output/encoder budget; not the definition of native sensor coverage |
-
-The attachment and reference execution budgets have distinct internal constants
-in `src/capture/raw-frame-limits.ts`. Producer and reconstruction share the latter
-because they admit the same full-native execution envelope. The JPEG output
-budget retains its separate meaning even though its current numeric value is
-the same. No safety limit is raised to make adjacent APIs appear identical.
-
-For example, a complete 64×65 attachment can be structurally valid, but its 4,160
-native sites exceed the reference reconstruction/producer budget even with a
-2×2 active/output crop. A 64×64 frame is within the inclusive 4,096-site budget;
-that fact alone does not supply missing kernel support or calibrated color.
-
-## Preflight and compatibility
-
-Call the existing stage parser before execution to discover incompatible
-requests. Parsers revalidate untrusted data and can copy/validate native records;
-this is not a constant-time dimensions-only capability query. Reconstruction
-rejects oversized sample arrays before creating an attachment snapshot. Export
-now rejects unsupported output resampling, uncovered final crop, incomplete
-active coverage for correction, and non-Bayer topology during parsing, before
-per-pixel reconstruction, rendering, hashes or file encoding. Bayer preflight
-requires exactly one red, two green and one blue site; an extra channel is
-rejected here rather than failing later during DNG packing.
-
-These are necessary structural gates, not a promise that execution succeeds.
-Kernel edge/source-channel support, DNG repeating black/common-white metadata,
-color-neutral validity, correction support and metadata encoding constraints
-retain their execution checks. Missing edge support still fails without
-padding, clipping or renormalization.
-
-Compatibility review: previously executable requests retain the same accepted
-envelope, arithmetic, codes, hashes and bytes. The public export parser now
-rejects these already-unsupported execution combinations earlier; when several
-faults coexist, error precedence can change. Existing diagnostic text is kept.
-No serialized field, schema or root API version changes, and no saved-data
-migration is required. Package and POC versions remain independent and unchanged.
-
-Larger/streaming execution remains unsupported. #16/#112/#178 are closed for their reviewed bounded scope; current execution/editor evidence is in [production capture](PRODUCTION_ENVIRONMENT_CAPTURE.md) and [export acceptance](EXPORT_ACCEPTANCE.md). Structural attachment alone does not establish that evidence for a new frame.

package/docs/RAW_FRAME_RECONSTRUCTION.md

@@ -1,30 +0,0 @@
-# Same-RAW reconstruction handoff (#16C)
-
-Release context: **package 1.2.0 candidate / root API 1.2.0**. Subsystem/model versions and dated introduction or measurement records below are independent historical identities; they are not distribution versions. See [developer navigation](DEVELOPERS.md) and [release contract](RELEASE_1_2_0.md).
-
-See [Reference RAW frame compatibility](RAW_FRAME_ENVELOPE.md) for stage-specific
-limits, full-native counting and parser preflight behavior.
-
-`resolveRawFrameReconstruction()` derives a bounded contiguous native-region virtual-sensor-channel plane from a committed `SensorRawFrame`. It delegates every output pixel to the existing #14 `resolveSensorRawReconstruction()`, using only exact attached RAW samples. Independent float planes in the attached capture are retained as history/metadata and **never provide reconstructed values**.
-
-This adapter and its RAW attachment predecessor are merged. Handoff schema 0.1.0 is retained; root API 0.99.0 was its historical introduction identity. Package/root API 1.0.1 uses aligned release identity; capture/production/POC contracts remain independent.
-
-Inputs are `rawFrame`, `region: { x, y, width, height }`, and `phaseProfiles: [{ phaseX, phaseY, profile }]`. A region is a positive integer half-open rectangle in the full native raster, not crop-local or oriented output coordinates. RAW-frame flags, dimensions, full native coverage, exact site/channel/code normalization and IDs are revalidated through #166.
-
-Every absolute CFA repeat phase must have exactly one explicit #14 reconstruction profile, matching the frame's capture-mode and color-sampling identities. All phase profiles expose the same output channels in the same order. Dispatch uses absolute native indices modulo the declared repeat dimensions; a cropped region never restarts phase. Input profile order is canonicalized to repeat-tile row-major phase order. No Bayer/X-Trans algorithm or RGB color basis is inferred from labels.
-
-For each pixel, the adapter gathers the exact required sites from the attached frame and checks bounds/channel assignment before calling #14. Existing declared normalized kernel weights own linear reconstruction; negative weights are permitted by that existing contract. Source values are the existing signed `blackSubtractedNormalizedCode`, not raw storage codes divided by container maximum. No new black subtraction, saturation/noise/gain equation or quantization is introduced.
-
-Missing edge sites fail closed. There is no edge replication, reflection, zero fill, dropped weight or renormalization. A caller may choose a smaller explicit region with fully available neighborhoods, but must not silently change intended final framing. Supplying a profile for every phase is not proof the kernel represents a calibrated or adequate reconstruction algorithm.
-
-The result includes an immutable exact source RAW-frame snapshot, phase profiles, region, interleaved native-region row-major plane and child calculation envelopes with exact weighted source contributions. The top-level scientific status remains **approximation** even if a profile labels itself calibrated; child status and assumptions are retained. No aggregate uncertainty is fabricated.
-
-`lineage = "engine-reconstructed-from-attached-raw"` means these returned values were actually computed from that returned RAW snapshot. `producerOriginVerified = false` retains #166's caller-declared producer boundary: no assertion is made that a caller originally ran the sensor pipeline. IDs alone do not establish equality; the exact snapshot and contributions remain inspectable. This is not cryptographic provenance, a signed certificate, RAW integrity metadata or a SimulationHash.
-
-The plane's image state is `virtual-sensor-channels`, and its raster binding is `native-reconstruction-region`; it is deliberately **not** an already-oriented `CaptureLinearPlane`. No WB, color conversion, physical orientation, final crop/resampling, sharpening, denoising or JPEG pipeline is applied. Sensor-channel labels do not define calibrated RGB primaries. A downstream explicit color-profile and geometry bridge is required before #112/#164 can accept these values. Existing capture float planes must not be substituted at that boundary.
-
-Reference safety limits: at most **4,096 full-native RAW sites**, **64 repeat phases**, **16 output channels**, and **256 total contributions per phase profile**. Region size cannot exceed that native frame. The reference adapter retains source snapshots and per-pixel traces and reparses lower-level profiles; it is not a 24/45/60 MP performance or memory claim. Larger/streaming execution requires measured separately reviewed work.
-
-Tests reuse #130-derived capture metadata and the shared synthetic RAW fixture. Declared 2×2 tile-average kernels are intentionally simple regression policy, not manufacturer demosaic or calibrated sensor color. Tests independently check arithmetic, direct lower-level equivalence, RAW-code changes versus unrelated float-plane changes, native phase/orientation invariance, malformed/stale inputs, edge rejection and safety bounds.
-
-Remaining #16/#112 work: producer-bound sensor execution, a defensible sensor color interpretation/profile, reconstruction-to-oriented-active/output geometry and color/WB processing handoff, metadata/hash/format mapping, DNG/JPEG writers and decoded/editor/memory acceptance. No issue is closed by this slice.

package/docs/RELEASE_1_0.md

@@ -1,66 +0,0 @@
-# 1.0.0 release contract and owner handoff
-
-**Historical 1.0.0 record.** The 1.0.0 release is published. This document preserves its preparation evidence and original policy snapshot. For current Node support, aligned package/root versions and the next owner release procedure, use [1.0.1 release preparation](RELEASE_1_0_1.md) and [NODE_SUPPORT.md](../NODE_SUPPORT.md).
-**Distribution:** `@photivra/engine@1.0.0` candidate. **Root API identity:** `0.116.0`. **Feature/science predecessor:** reviewed/signed main `34c6d9aca1c2e365b253c1562734d11bc8e0235f` (PR #206), tree `fa74373967843a1942206c26f5baa004e9a466fd`. Its post-merge CI 37032338620 passed Node 22.13.0/24 with 1,598 tests / 142 files. The release-preparation PR/CI identifies the exact new candidate; after signed squash merge, verify its tree equality and record final main SHA in the issue/PR handoff. A commit cannot contain its own cryptographic commit/tree identifier without a circular dependency.
-
-## What 1.0 contains
-
-The V1 feature/science checklist is 32/32 and required defect #178 is closed. The root includes explicit camera/sensor/capture geometry, optics, focus, exposure control, registered illumination, bounded motion/stabilization, spectral/response/charge/noise/readout foundations, generic tier assets, immutable production plans, linear/color/SDR processing, and same-RAW paired DNG/JPEG export. See [developer navigation](DEVELOPERS.md) and [composition/consumer map](V1_COMPOSITION_MAP.md) for actual entry points and supported combinations.
-
-The declared environment production route can execute all fourteen graph stages through native RAW and optional output. It retains a full-native 4,096-site budget and 100,000-provider-evaluation aggregate cap, exact one-to-one CFA timing, scene time zero, ideal environment projection/constant-axis rotation, explicit unity field throughput and optional destination-local sampled PSF. Paired reference export supports registered Bayer and 1:1 output cropping. Structural RAW attachment has a separate 65,536-site ceiling and does not authorize larger execution.
-
-The package does not supply a general surface renderer/visibility solution, calibrated commercial profiles, full field-dependent PSF transport, megapixel processing, HDR output, multi-frame computational image combination, C2PA, hosted API or MCP server. Generic assets and provider output remain approximations. A stable API does not establish calibrated physical accuracy, universal tier ranking, combined uncertainty, browser frame time or typical-resolution peak memory. Export/editor evidence and limits remain in [acceptance](EXPORT_ACCEPTANCE.md).
-
-## Migration and independent identities
-
-The distribution moves from 0.6.0 to 1.0.0. Root contract **0.116.0 is retained**, rather than mechanically reset to 1.0.0: no exported operation shape, scientific arithmetic, default, seed schedule or serialized capture identity changes in this preparation. This is an intentional independent contract identity under the package's new stable policy, not permission to keep making undocumented pre-1.0 breaks. Existing 0.116 callers require no code/data migration for this release preparation.
-
-Users of earlier development contracts must apply their actual intervening migrations. In particular, old producer noise model 0.1.0 cannot silently replay the signed-shadow correction: current producer noise model is 0.2.0, readout provenance model 2.0.0. Deliberate recomputation preserves historical artifacts and records new identity. Capture schema 0.1.0 archives normalize to 0.2.0 while retaining creator API identity; normalized bytes change. Production plan 0.7.0 / consumer manifest 0.2.0 add bounded environment execution fields. See the governing capture/producer/composition guides and historical changelog. Do not compare version strings from different contracts as though they form one global schema version.
-
-POC API 0.20.0, image-formation ordering 0.4.0, production capture snapshot 0.3.0, tier assets 1.0.0 and every other schema/model keep their existing independent values. Root API 0.116.0 still exports all original scientific operations. Documentation-only comments and reference generation do not authorize recomputation of historical calibrated data or fixture hashes.
-
-After 1.0, compatible additions use package minor releases, compatible fixes/docs use patches, and breaking root exports, semantics or unsupported reinterpretation of previously valid data require a documented package major transition and relevant independent contract changes. Prefer additive deprecation with an explicit migration and documented removal version. No fixed deprecation duration is promised. Necessary scientific/security corrections must be explicit even when preserving incorrect behavior would appear easier. No substantial optional public-engine feature work starts by default after V1; maintenance, corrective science, validation and security continue.
-
-## Exact candidate verification
-
-Use the lockfile and maintained Node 22/24 CI policy, preferably patched Node 24 for tooling:
-
-```sh
-npm ci
-npm run check
-npm run coverage
-npm run build
-npm run pack:check
-npm run docs:check
-npm run release:consumer-check
-npm run bench:image-formation:built
-```
-
-`docs:check` verifies reference synchronization, local/public repository links, imported symbols and explicitly recorded complete/fragment examples. The consumer check packs once into a temporary directory, installs the tarball with scripts disabled, validates declarations with strict TypeScript and executes complete examples plus the bounded production/export example without a source checkout. CI runs these release-specific checks on both supported runtimes. Existing science/license/SPDX/browser/package/coverage gates remain unchanged.
-
-Local macOS full tests retain the previously reproduced unchanged-main `equivalence-38` exact hash difference. No reference was regenerated. Linux CI is the exact-head full-suite authority; recorded cross-platform deterministic limitations must remain visible rather than weakening that assertion. Existing performance and external-editor acceptance evidence applies because runtime arithmetic and independent models are unchanged; release comments/version metadata are additionally checked against the packed artifact.
-
-## Owner-only tag and publish procedure
-
-This ticket prepares the repository; it creates no tag, npm publication or GitHub release. First substantively review the release contribution and certify DCO 1.1 for the signed merge. Merge only the tested candidate, verify final-main CI and record its commit/tree. Confirm current main still equals that final commit immediately before tagging; keep it unchanged through workflow verification.
-
-The current `.github/workflows/publish.yml` triggers on pushed `v*` tags. It requires **`v1.0.0`**, matching package/lock/citation metadata, at **current main**, with protected main and a protected tag. Public API inspection on 2026-10-02 confirmed main protected and an active tag ruleset applying to `refs/tags/v*`, blocking creation/update/deletion except authorized bypass. Only an authorized owner can create the release tag; do not weaken those controls.
-
-From a clean owner checkout, replace `FINAL_MAIN_SHA` with the verified merged commit:
-
-```sh
-git fetch origin main --tags
-git switch main
-git pull --ff-only origin main
-test "$(git rev-parse HEAD)" = "FINAL_MAIN_SHA"
-test "$(git rev-parse origin/main)" = "FINAL_MAIN_SHA"
-test "$(node -p "require('./package.json').version")" = "1.0.0"
-git tag -a v1.0.0 FINAL_MAIN_SHA -m "Photivra engine 1.0.0"
-git push origin refs/tags/v1.0.0
-```
-
-The **tag push automatically starts npm publication**; publishing a GitHub release alone does not. The workflow checks the maintained LTS policy, installs locked dependencies with scripts disabled, verifies science/coverage/static/docs/consumer/build/package gates, then packs the verified artifact. A separate minimal OIDC job downloads it, checks SHA-256 and publishes public npm only if that exact version is absent. It requires npm >=11.5.1 and the configured trusted publisher for this repository/workflow. That npm account-side configuration is not inspectable through the repository connector and is an owner account prerequisite; no credential or publishing identity is used during this ticket.
-
-Watch the publish workflow until success. Verify npm reports 1.0.0 and record the published tarball integrity. Then create the owner GitHub release at `v1.0.0`, using these release notes and the final commit/check evidence. If verification fails, retain the failure and investigate; do not force-move a protected tag or bypass science/provenance gates.
-
-The site-side handoff is in [developer navigation](DEVELOPERS.md); no website deployment or unpublished route is required. #165 remains post-V1.

package/docs/RELEASE_1_0_1.md

@@ -1,61 +0,0 @@
-# 1.0.1 release preparation and migration
-
-**Candidate distribution and root API:** `@photivra/engine@1.0.1` and `ENGINE_API_VERSION = "1.0.1"`. The published predecessor is [1.0.0](https://github.com/Photivra/photivra/releases/tag/v1.0.0), whose root API identity was 0.116.0. This change prepares the next release; 1.0.1 installation becomes available only after owner publication.
-
-## Changes
-
-- Support all upstream-supported Active LTS and Maintenance LTS Node.js lines plus Current. The reviewed 2026-10-02 set is maintained Node 22 (minimum 22.13), maintained Node 24 and Node 26 Current.
-- Test patched 22/24/26 and minimum 22.13.0 in CI. Every matrix job runs lifecycle checks, locked installation, static/scientific tests, build, documentation, isolated packed consumers and package checks. Node 24 also runs coverage and the informational benchmark.
-- Align the full package and root API version at 1.0.1. Automated checks prevent drift between source, package/lock/citation metadata, generated reference and the real packed consumer.
-
-The preferred build/development baseline and pinned Node typings remain 24. The manifest minimum remains >=22.13.0; this broad range is not a qualification of unknown or EOL majors. Use current patches in ordinary development. See [the runtime policy](../NODE_SUPPORT.md) for Current-to-LTS and EOL boundaries, snapshot review and future-major maintenance.
-
-## Migration and preserved contracts
-
-No exported operation shape, scientific equation, default, seed schedule, dependency or accepted processing envelope changes. Schema/model/POC/production-plan contracts retain their independent versions; POC remains 0.20.0 and the production plan remains 0.7.0.
-
-Starting with this release, `ENGINE_API_VERSION` identifies the same release as the npm package. Consumers that compared it with the literal 0.116.0 must update that comparison or use the exported constant. Do not equate this root release identity with an independent schema/model version.
-
-Newly created captures and plans record creator root API 1.0.1. That metadata can change serialized bytes, plan fingerprints and capture/export identity hashes even when scientific values are equal. Archive parsers retain the creator identity recorded by earlier releases; they do not relabel an existing capture as 1.0.1. Historical fixtures, checksums, benchmark reports and introduction-time versions remain historical evidence. Any deliberate recomputation must create new artifacts with their actual creator/version identity.
-
-The bounded V1 capabilities and scientific limitations are unchanged. See [developer navigation](DEVELOPERS.md), [the original 1.0 release contract](RELEASE_1_0.md), and each domain's current guidance. Node compatibility does not establish calibrated physics, browser performance or megapixel processing.
-
-## Candidate validation
-
-Use patched Node 24 for ordinary release preparation, then require green CI for all supported majors:
-
-```sh
-npm ci --ignore-scripts
-node --test .github/test-node-lts-policy.mjs
-node .github/node-lts-policy.mjs
-npm run check
-npm run coverage
-npm run build
-npm run docs:check
-npm run release:consumer-check
-npm run pack:check
-npm run bench:image-formation:built
-```
-
-The exact submitted commit and CI outcome are recorded in the review PR. The known unchanged-main Mac `equivalence-38` hash difference remains explicit; Linux CI is the full-suite authority. No golden/assertion or scientific tolerance is relaxed for this release.
-
-## Owner release procedure
-
-After substantive human review, contribution-specific DCO certification and merge of the tested candidate, require green final-main CI and verify that its tree matches the approved candidate. Confirm npm trusted publishing and protected main/tag rules remain configured. This preparation performs no tag, npm publication or GitHub release.
-
-From a clean owner checkout, replace `FINAL_MAIN_SHA` with that verified merged commit:
-
-```sh
-git fetch origin main --tags
-git switch main
-git pull --ff-only origin main
-test "$(git rev-parse HEAD)" = "FINAL_MAIN_SHA"
-test "$(git rev-parse origin/main)" = "FINAL_MAIN_SHA"
-test "$(node -p "require('./package.json').version")" = "1.0.1"
-git tag -a v1.0.1 FINAL_MAIN_SHA -m "Photivra engine 1.0.1"
-git push origin refs/tags/v1.0.1
-```
-
-The tag push starts the existing protected publish workflow. Its verification job uses Node 24 and the Node support guard before dependency installation, checks tag/version/current-main identity and all existing release gates, and creates the verified tarball. The separate OIDC publication job checks that artifact's SHA-256 and publishes only if the exact version is absent. Do not change the published 1.0.0 release or move an existing protected tag.
-
-Watch the workflow to completion, verify public npm exposes 1.0.1 and record tarball integrity, then create the GitHub release at v1.0.1 using the final commit and check evidence. Report any failure and investigate rather than bypassing a gate.

package/docs/RELEASE_1_1_0.md

@@ -1,25 +0,0 @@
-# 1.1.0 candidate review and migration
-
-This is an additive, unpublished candidate after the 1.0.1 baseline. Package version and root `ENGINE_API_VERSION` are both 1.1.0. New standalone Print APIs are documented in [Print planning](PRINT_PLANNING.md). No existing scientific API is removed or reinterpreted; POC, capture schemas, formation graph and production-plan versions remain unchanged.
-
-New capture/plan records created by this candidate carry root creator identity 1.1.0 and their hashes may change. Historical captures, qualified fixture files, measured artifacts and earlier release documents retain their original identities. A version bump is not renewed scientific qualification or printer-quality evidence. Use the exact reviewed release and its packaged documentation; this candidate is not yet available on npm.
-
-Required review: public contract and exact-ratio policy, angular convention, independent numerical/geometry evidence, source/reuse rights, native-authority binding, no-upscale provider conflicts, backward compatibility and substantive human review of AI-assisted draft material. Review all DCO sign-offs before inclusion. Print planning does not activate exporting, perceived-quality assessment or production rendering.
-
-Run the existing release gates without weakening them:
-
-```sh
-npm ci
-npm run check
-npm run coverage
-npm run build
-npm run pack:check
-npm run docs:check
-npm run release:consumer-check
-```
-
-Regenerate the root reference with `node scripts/generate-api-reference.mjs`. Strict examples run from an isolated packed ESM consumer with no source deep imports or runtime dependencies. Review CI across supported Node versions and inspect the actual package before owner tag/publication. The prior [1.0.1 procedure](RELEASE_1_0_1.md) remains historical; use 1.1.0 identities for this candidate and do not republish an existing version. Merge, tag and npm publication are separate owner decisions. No such action is performed by preparing this draft.
-
-## Bounded diagnostic extension
-
-The stacked #196 first slice adds the [regional coherent-grating diagnostic](PRINT_DETAIL_ASSESSMENT.md) and [independent protocol](PRINT_DETAIL_VALIDATION.md) to this unpublished candidate without changing Print model 0.1.0 or existing contracts. It validates mathematical coefficients and reference geometry only; acquired-image/backend, noise/artifact/perception and full scoped Print-release acceptance remain blocked in the ledger. Preparing or publishing the diagnostic must not imply those qualifications are complete. Reconcile candidate contents and human review before tagging; no 1.1.0 distribution has been published by this work.

package/docs/RELEASE_1_2_0.md

@@ -1,51 +0,0 @@
-# 1.2.0 candidate review and migration
-
-The additive package/root candidate is `@photivra/engine@1.2.0`. npm registry verification on 2026-10-03 found published 1.1.0 as the baseline; 1.2.0 was absent. This change prepares an unused minor release, without moving an existing tag or overwriting a distribution. Review the [native SDR contract](NATIVE_CAPTURE_SDR.md) and [validation evidence](NATIVE_CAPTURE_SDR_VALIDATION.md).
-
-## Compatibility
-
-Existing public APIs, small inline reference guards and scientific equations remain unchanged. The new metadata-only tiled executor supports explicitly resolved external linear-sRGB/D65 masters up to 24 MP, with bounded tile storage and single-transfer 8/16-bit output. It is not general scalable XYZ/WB/RAW/correction/resampling/JPEG execution. It does not activate production-plan stages, qualify producers/devices or complete Print quality acceptance. Existing post-1.1.0 bounded regional Print diagnostic work on main retains its stated limits and separate #196 qualification gates.
-
-Package version, lock root, citation and `ENGINE_API_VERSION` are aligned at 1.2.0. Newly created capture/plan records carry this creator identity and their serialized identities/fingerprints/hashes may change. Archived captures retain the original creator identity, and historical fixtures/hashes/measurement records remain unchanged. Native SDR schema 0.1.0, capture/model/POC/production-plan versions remain independent. JPEG golden regression replays the manifest-recorded creator version through the existing archive parser; it also verifies current exports record the actual current creator and preserve integer pixels. Historical JPEG bytes/hashes and independent decoder records are not regenerated. Old consumers continue using their existing APIs; new consumers must import the reviewed 1.2.0 root surface rather than deep imports.
-
-## Review and checks
-
-Substantive human scientific/source review must cover supported color/WB states, source authentication/provider restrictions, geometry identity, typed-buffer ownership, cancellation/draining, measured resource limits, unchanged reference arithmetic and compatibility. Review contribution-specific DCO certification. An AI draft does not certify reusable source rights, device performance or calibration.
-
-PR #216 received human scientific/source and contribution-specific DCO approval and was squash merged as `5dfb9a24c683dad5529cbd579ffecf2baeec2c27`. Its reviewed tree and supported Node CI were verified. The [technical review record](NATIVE_CAPTURE_SDR_REVIEW.md) preserves the evidence history. The follow-up strengthened float32/float64 policy parity, orientation pixels, pending WB/shared-buffer rejection, host-yield cancellation and maximum 24 MP/16-bit measurements. No tag or package was published.
-
-The subsequent combined #195/#196 work received separate owner scientific/source and DCO approval at head `43e4e9e4baac90f7b16c6e068b7964c0546a8134` and was squash merged as `c58d9eb9dcba807f020df45be1ed5ec4f6c081e4` in [PR #217](https://github.com/Photivra/photivra/pull/217). The approved tree is preserved, all 2,065 tests pass and post-merge CI is green on all four supported Node versions. #195 is complete. The old [candidate review record](PRINT_195_196_REVIEW.md) preserves its pre-approval evidence. The follow-up [engine #196 acceptance audit](PRINT_196_ENGINE_ACCEPTANCE.md) adds patterned-source native-capture qualification and separates engine acceptance from the still-required app acquisition/proof/accessibility/device gates. That additional scientific/source material needs review and DCO certification before #196 engine acceptance; the requested engine release remains held for that acceptance and explicit publication approval. Full new-UI qualification remains outstanding in its app owners.
-
-Run from the exact candidate tree, then require green supported Node 22.13/22/24/26 CI:
-
-```sh
-npm ci --ignore-scripts
-npm run check
-npm run coverage
-npm run build
-node scripts/generate-api-reference.mjs --check
-npm run docs:check
-npm run release:consumer-check
-npm run pack:check
-npm run bench:image-formation:built
-node --expose-gc scripts/benchmark-native-capture-sdr.mjs
-```
-
-No gates or thresholds are weakened. Benchmark results are host-specific observations; device/provider/master/encoder memory must be measured separately before app activation.
-
-## Owner publication
-
-After human review and merge, verify final-main CI and the approved candidate tree. Confirm protected main/tag rules and npm trusted publishing are configured. Replace `FINAL_MAIN_SHA` below with the verified final merged commit. Recheck that 1.2.0 remains unused. This PR creates no tag and publishes no package.
-
-```sh
-git fetch origin main --tags
-git switch main
-git pull --ff-only origin main
-test "$(git rev-parse HEAD)" = "FINAL_MAIN_SHA"
-test "$(git rev-parse origin/main)" = "FINAL_MAIN_SHA"
-test "$(node -p "require('./package.json').version")" = "1.2.0"
-git tag -a v1.2.0 FINAL_MAIN_SHA -m "Photivra engine 1.2.0"
-git push origin refs/tags/v1.2.0
-```
-
-The existing protected workflow verifies tag/main/version and release gates, produces the verified tarball, checks its SHA-256 and uses OIDC to publish only an absent version. Observe completion, verify npm 1.2.0 metadata/tarball integrity, then create the matching GitHub release with the approved changes and evidence. Preserve publication failures for investigation; do not bypass gates, move tags or mutate a published version. #215's publication acceptance remains pending until the reviewed distribution exists.

package/docs/RELEASE_1_3_0.md

@@ -1,15 +0,0 @@
-# Photivra engine 1.3.0 release
-
-This minor release adds evidence-bound radial illumination throughput to bounded environment photo/RAW capture, merged in PR #219. Attenuation is applied exactly once before normalized PSF redistribution; every inverse-PSF tap is validated before provider callbacks. Existing unity-throughput arithmetic and resource limits are preserved. No new dependency, calibration claim, or transport qualification is introduced.
-
-## Compatibility and migration
-
-Existing unity-throughput requests remain supported. Requests using the new non-unity field profile must explicitly request the illumination-vignetting fidelity effect in production composition. Invalid or undeclared attenuation fails before provider callbacks. The photo integration model advances independently to 0.2.0.
-
-Package, lock root, citation and ENGINE_API_VERSION are aligned at 1.3.0. New capture/plan creator identities and hashes may change; archived records retain their original creator identity. Historical fixture bytes and independent model/schema/POC/plan versions are preserved.
-
-## Validation and publication
-
-The owner requested immediate release on October 4, 2026. PR #219 already received owner scientific/source review and passed supported Node CI. This release preparation changes metadata and documentation only. Require static policy, tests/coverage, build, generated references, documentation, isolated packed consumer, package-surface and supported Node CI checks on the final release tree.
-
-After merge and successful main CI, create the unused annotated v1.3.0 tag at the verified main commit. The protected publish workflow rechecks tag/main/version and all distribution gates, verifies the tarball checksum and publishes through npm trusted publishing. Observe successful publication and then create the matching GitHub release. Never move tags or overwrite published versions.

package/docs/RELEASE_1_4_0.md

@@ -1,23 +0,0 @@
-# Engine 1.4.0 candidate release review
-
-This additive candidate aligns package, lockfile, citation and root engine identity at 1.4.0. It is not tagged or published. The application's production dependency remains the published 1.2.0 package until an approved release and explicit consumer migration.
-
-Changes include the previously merged ideal pupil support and the separate metadata-only packed native RAW, source-to-RAW, same-RAW development and bounded post-SDR Print JPEG/ICC APIs. Independent schema versions remain 0.1.0. Reference inline plane, RAW and photographic export caps remain unchanged. Shared scalar helpers preserve the existing charge/noise/ADC, reconstruction, color and SDR equations. Reference JPEG byte controls cover eighteen original encoder cases including odd padding, three quantization steps and empty metadata.
-
-See [native contracts and reproducible evidence](NATIVE_RAW_AND_PRINT.md), [pupil contract](SENSOR_APERTURE_RAYS.md), and [recorded controls](validation/native-raw-print-2026-10-04/validation.json).
-
-## Review boundaries
-
-The new tasks execute complete constructed capture inputs; they do not authenticate caller-owned artifact hashes or calibrate arbitrary source callbacks. Source radiometry/visibility, quadrature convergence, device resources, production stage composition, printer appearance and platform delivery remain separate contracts. Full production depth composition remains closed. The new native event records are deliberately separate from bounded `SensorRawFrame` and cannot be inserted into it as fabricated small frames.
-
-The public engine contains original Apache-licensed math, serialization and synthetic controls only. Private application scene sources, fixture assets and proprietary adapters are retained in the application repository. The original ICC profile uses standard format/color facts, not a redistributed profile or encoder implementation.
-
-## Owner handoff
-
-1. Review the exact candidate code and public source provenance, scientific domains, unit/frame/phase/seed binding, resource limits and disposal behavior. AI-assisted changes remain draft until substantive human review under AGENTS.md.
-2. Require green exact-head CI on Node 22.13, 22, 24 and 26, plus the package, documentation and isolated consumer gates. The optional actual megapixel run is separately recorded; its ordinary-suite skip is explicit.
-3. Approve merge and the concrete 1.4.0 release only after review. Merge must not silently publish a tag. Check final main/commit/version identity and unchanged package consumer acceptance.
-4. With explicit publication approval, use the repository release procedure/workflow for GitHub and npm. Confirm the published tarball, root export, version and provenance before migrating the application. Do not treat local candidate tooling as a published production import.
-5. Finish the application’s independently retained source, output, platform and human/device acceptance at the adopted published version, then approve the concrete production deployment.
-
-No tag, publication, production activation, credential change or deployment is authorized by this document.