@wenathlan/saddle 2.1.6 → 2.1.8

package/docs/{repo-synthesis-1.8.16.md → reposynthesis1816.md}

@@ -2,7 +2,7 @@
 
 ## Scope and evidence boundary
 
-This synthesis evaluates the 100 primary repository sources recorded in [repo-research-1.8.16.md](./repo-research-1.8.16.md). It does not copy source code, vendor dependencies, credentials, workflow configuration, service setup, operating assumptions, or claims of the reviewed projects. A candidate that lacked successful primary extraction is retained only as a pending source and is not used as implementation evidence.
+This synthesis evaluates the 100 primary repository sources recorded in [reporesearch1816.md](./reporesearch1816.md). It does not copy source code, vendor dependencies, credentials, workflow configuration, service setup, operating assumptions, or claims of the reviewed projects. A candidate that lacked successful primary extraction is retained only as a pending source and is not used as implementation evidence.
 
 The current baseline is Saddle 1.8.15. It already has deterministic storage pools and budgets, working-set planning, archive inspection, transform cache eligibility, provider-chain selection and cancellation plans, declarative delivery/PWA/surface requirements, release asset generation and local checksum verification. The selected 1.8.16 additions must remain additive, TypeScript-first, root-first, dependency-free, serializable and adapter-owned for all privileged or remote effects.
 

package/docs/todo.md

@@ -696,9 +696,9 @@ The following blocks are the execution order for the complete ecosystem. A block
 
 - [x] Read the supplied scope references in full, distinguish verified constraints from aspirational proposals, and preserve both files unchanged.
 - [x] Map the active 1.8.14 engine, exports, tests, package surfaces and release rules against the realistic 1.8.15 opportunity set.
-- [x] Create `docs/todo-1.8.15.md` with more than 400 individually checkable research, contract, implementation, test, documentation, validation and release steps.
+- [x] Create `docs/todo1815.md` with more than 400 individually checkable research, contract, implementation, test, documentation, validation and release steps.
 - [ ] Define a public-repository research rubric and category quota for the 1.8.16 comparative analysis, targeting 100–300 relevant repositories without treating any external implementation as a copy source.
-- [x] Create `docs/todo-1.8.16.md` with 600–900 individually checkable steps covering repository research, evidence capture, gap selection, implementation, tests, documentation, release and post-release verification.
+- [x] Create `docs/todo1816.md` with 600–900 individually checkable steps covering repository research, evidence capture, gap selection, implementation, tests, documentation, release and post-release verification.
 - [x] Review both versioned plans for architectural constraints, security, feasibility, feature ownership and release-gate dependencies before beginning implementation.
 
 ### Authorized execution order

package/docs/{todo-1.8.15.md → todo1815.md}

@@ -470,7 +470,7 @@
 - [ ] Verify all active version manifests remain at 1.8.14 until implementation and release notes are ready.
 - [ ] Bump all active version manifests to 1.8.15 only after the release candidate is validated.
 - [ ] Update the iOS build number to 1008015 only as part of the validated version bump.
-- [ ] Create docs/releasenotes-1.8.15.md from verified claims and the real generated artifact inventory.
+- [ ] Create docs/releasenotes1815.md from verified claims and the real generated artifact inventory.
 - [ ] Update changelog.md with concise, evidence-backed 1.8.15 entries.
 - [ ] Update docs/artifactavailability.md using only post-build and post-release evidence.
 - [ ] Create a commit authored as iakadion after the full local gate passes.

package/docs/{todo-1.8.16.md → todo1816.md}

@@ -541,7 +541,7 @@
 - [x] Derive the 1.8.16 verification check for release evidence only after comparative evidence identifies a concrete gap that does not duplicate an existing Saddle capability. Completed by deterministic acceptance, insufficiency, mismatch, and readiness tests in `tests/engine.test.ts`.
 - [ ] Derive the 1.8.16 workflow test for release evidence only after comparative evidence identifies a concrete gap that does not duplicate an existing Saddle capability.
 - [x] Derive the 1.8.16 failure policy for release evidence only after comparative evidence identifies a concrete gap that does not duplicate an existing Saddle capability. Completed by ordered `rejected` and `insufficient` reason codes without positive assurance claims.
-- [x] Derive the 1.8.16 documentation for release evidence only after comparative evidence identifies a concrete gap that does not duplicate an existing Saddle capability. Completed in `docs/enginearchitecture.md` and `docs/repo-synthesis-1.8.16.md`.
+- [x] Derive the 1.8.16 documentation for release evidence only after comparative evidence identifies a concrete gap that does not duplicate an existing Saddle capability. Completed in `docs/enginearchitecture.md` and `docs/reposynthesis1816.md`.
 - [ ] Derive the 1.8.16 contract for cross-runtime compatibility only after comparative evidence identifies a concrete gap that does not duplicate an existing Saddle capability.
 - [ ] Derive the 1.8.16 capability matrix for cross-runtime compatibility only after comparative evidence identifies a concrete gap that does not duplicate an existing Saddle capability.
 - [ ] Derive the 1.8.16 import graph audit for cross-runtime compatibility only after comparative evidence identifies a concrete gap that does not duplicate an existing Saddle capability.
@@ -626,15 +626,15 @@
 
 ## 8. Documentation, compatibility, and release execution
 
-- [ ] Update docs/repo-research-1.8.16.md with the complete selected repository inventory and source evidence.
+- [ ] Update docs/reporesearch1816.md with the complete selected repository inventory and source evidence.
 - [ ] Update docs/repo-analysis-1.8.16.json with structured metadata, classification, source paths, and implementation disposition for every analyzed repository.
-- [ ] Update docs/repo-synthesis-1.8.16.md with feature-gap rankings, accepted patterns, rejected patterns, and implementation rationale.
+- [ ] Update docs/reposynthesis1816.md with feature-gap rankings, accepted patterns, rejected patterns, and implementation rationale.
 - [ ] Update docs/gapmatrix.md only after comparing the implemented result against the final 1.8.16 code and tests.
 - [ ] Update README claims only when a corresponding capability is public, tested, documented, and not caller-owned or speculative.
 - [ ] Update package exports only for stable, explicitly documented additive contracts.
 - [ ] Update type declarations and package-import tests for every export-map change.
 - [ ] Update changelog.md from verified completed work rather than the original research hypothesis.
-- [x] Create docs/releasenotes-1.8.16.md only after artifact inventory, signing status, workflows, and registry results are known. The final release record lists 38 attached assets and the manual Android fallback state.
+- [x] Create docs/releasenotes1816.md only after artifact inventory, signing status, workflows, and registry results are known. The final release record lists 38 attached assets and the manual Android fallback state.
 - [x] Update docs/artifactavailability.md only from generated and remotely verified release evidence. The 1.8.15 and 1.8.16 matrices use published release inventories.
 - [x] Run npm test, legacy tests, web typecheck, web build, formatcheck, package dry-run, high-severity audit, and flat-native validation on the final candidate. The candidate passed 136 active and 69 legacy tests with all required gates.
 - [x] Review CI workflows for tag-derived versioning, no hardcoded release version, no exposed secrets, and no unverified publish claim. Tag-triggered registry and asset workflows completed with explicit signing-state boundaries.
@@ -670,7 +670,7 @@
 - [x] Compare requested operating-system and architecture combinations against Docker Buildx, OCI image-index, Node runtime, and runner support.
 - [x] Distinguish publishable Linux OCI variants from Windows container variants that require a compatible Windows base image and Windows runner.
 - [x] Avoid claiming an `unknown` platform as a runnable operating-system or architecture target.
-- [x] Select a supported 1.8.17 Linux multi-architecture matrix and record rejected or deferred combinations with their technical reason in `docs/containerplatforms-1.8.17.md`.
+- [x] Select a supported 1.8.17 Linux multi-architecture matrix and record rejected or deferred combinations with their technical reason in `docs/containerplatforms1817.md`.
 - [x] Review the current container workflow, image base, tags, OCI labels, post-push pull, label verification, and smoke test before modifying it.
 - [x] Extend the container workflow only for platform combinations that can build and execute the packaged Saddle runtime: `linux/amd64`, `linux/arm64`, and `linux/ppc64le`.
 - [x] Keep release-tag version derivation, registry credentials, permissions, and the container-first documentation order intact.

package/docs/workloadlaw.md

@@ -0,0 +1,104 @@
+# the workload law — the family lane catalog and the join of record
+
+> wave WL1 — the answer to the owner's charge: the system and every step
+> of it ride the saddle, the visitor browser, gpu, cpu and storage are
+> never touched, and the ninety modality modalities of the engine answer
+> the family's work over the internet.
+
+## the law
+
+The engine already carried the nuclear modality law since wave SV1
+(`modalityregistry.ts`): the workload never chooses a modality by name —
+the join resolver reads the demand (isolation, gpu, network, boot budget)
+and answers the modality set that satisfies it, so the person chooses
+none and the platform resolves the join of all. Until this wave the law
+was a declared spine without a caller: the registry was a catalog and a
+report, no lane of any app ever asked the join a question, and the
+debonair worker seat named modality ids by hand without a resolver behind
+them.
+
+The workload law (`workloadlaw.ts`) makes the nuclear law executable for
+the whole family:
+
+1. **The catalog** — `FAMILYLANES` carries one row per heavy workload
+   lane of every official app of the monorepo: the app that owns the
+   lane, the lane id, the role sentence, the demand (gpu, network,
+   isolation depth, boot budget) and the honest today (`engine-lane` when
+   the heavy pass already runs on a server-side engine surface,
+   `app-lane` when it still walks inside the app surface). The analysis
+   wave (A1) mapped all thirty-six lanes from the real modules of the
+   eleven apps.
+2. **The join** — `lanejoin` rides the registry's `resolvejoin` for each
+   row's demand and answers the ordered candidate set with the honest
+   verdict: `dispatchable` (at least one live modality satisfies the
+   demand), `planned-only` (only planned records answer — the gpu lanes
+   ride here today and say so) or `unresolved` (a calibration defect the
+   battery refuses).
+3. **The census** — `workloadreport` folds the per-app joins into the
+   family work order: the dispatchable count, the planned-only wait, the
+   app-lane migration list (the lanes whose heavy pass still walks the
+   app surface — the next waves' honest backlog), nothing hardcoded.
+
+Every row carries a demand and never a modality id — the candidates are
+computed from the registry of record, so a modality that turns live
+tomorrow answers the same lane without this file moving.
+
+## the family mirrors
+
+Each app of the family carries `sandboxmodality.ts` — the mirror of its
+own rows in the engine catalog, plus the deploy's opt-in seat:
+
+- `WORKLOADLANES` — the mirrored lane rows (the lockstep string contract:
+  mirrored, not imported, because the published saddle envelope does not
+  carry the workload law yet and the family law bars relative paths
+  across apps — the same discipline the devthink modalities vendor
+  rides).
+- `<APP>_SANDBOX_LANE` — the deploy's seat: `local` (the default, the
+  deploy's own process), `join` (the platform resolves every lane through
+  the engine's join resolver), or a pinned modality id (named by the
+  deploy, validated by the platform's join at dispatch — the app module
+  never judges engine vocabulary, so the mirror cannot drift when the
+  registry grows).
+- The debonair keeps its worker seat (`DEBONAIR_WORKER_MODALITY`) beside
+  the family seat — the two coexist honestly: the worker seat pins the
+  worker process, the lane seat declares the lanes to the platform.
+
+Every app battery pins its mirror against the engine catalog through the
+vitest bridge (`@wenathlan/saddle/workloadlaw` → the monorepo source),
+comparing lane, role, demand and today row by row — the vendor can never
+drift in silence. The bridge retires when the published envelope carries
+the built workload law.
+
+## the api surface
+
+The self-hosted web console (`webserver.ts`) answers the law over the
+`/api/v1` contract:
+
+- `GET /edge/workloads` — the family census: the workload report, the
+  probed lane table of the edge plane and the app list, one round trip.
+- `GET /edge/join?app=&lane=` — the nuclear law as a lookup: the workload
+  names its app and lane, the resolver answers the ordered candidate set
+  with the honest verdict. A 404 answers an unknown app or lane (the
+  honest refusal, never a silent empty join).
+
+## the honest first census
+
+The first reading of the law over the current registry (30 live, 3 host,
+57 planned modalities):
+
+- thirty-five of the thirty-six lanes resolve dispatchable — at least
+  one live modality satisfies every demand except the gpu wait;
+- `stealthhead/world-bake` answers planned-only — every gpu record of the
+  registry is planned today, and the lane says so instead of pretending
+  (the first gpu modality that turns live answers it without any file
+  moving);
+- sixteen lanes still walk the app surface (`app-lane`) — the seeded
+  rehearsals of forge and foundry, the browser fallbacks of argan's
+  catalog, the decode lane of cadria, the simulation walks of
+  stealthhead: the honest migration list the next waves work through,
+  lane by lane, each one a deploy that seats `join` and a platform that
+  dispatches through the edge plane.
+
+The lane table, the join and the census are the wiring truth of this
+law: a lane that does not ride the saddle says so, a lane that can ride
+tomorrow is named, and nothing pretends.