123: two-layer kernel, cost in simulation time, Forecast tab; 124 spec

[IanMayo]

What this changes, and why

Two things the SRD gained today and the tree did not have: a model that propagates rather than translates, and a surface that shows a forecast being made. Feature 123 is built here; feature 124 is specified, and the parts of it that were never actually blocked are built too.

The kernel. shallow-two-layer-v1 joins shift-advect-v1 behind the unchanged model kernel port (Constitution VI): upwind advection, explicit horizontal diffusion and interfacial exchange, with an internal sub-step count derived from a stability condition and a refusal — naming the numbers — past max_sub_steps.

Cost is simulation time (ADR-0043). The kernel reports its work, the configuration declares a rate, and a run occupies the ticks it costs rather than taking a third wall-clock exemption. check-declared-cost fails the build if a component declares cost in any other currency.

Affordability is inverted, and that is the whole of FR-31. A warranted run is held while the standing forecast has more life than the run's cost plus the release margin, and released as headroom decays. Read the obvious way round the loop becalms permanently, because the run that would restore validity is exactly the one never affordable.

#/view/forecast now shows the forecast, which for two rounds it did not. It opened with a gauge about the run loop, a cost, a list of runs, and two regions naming feature 124 for the whole of themselves. Both turned out to be mostly buildable:

• "What next" draws the forecast's own features in plan — the eddy, the drifting feature and the front across the lead steps, each with its uncertainty widening; the thermocline stated in figures, because a depth has no place in a plan view. ctl/forecast/features is FR-05's entire product and had no consumer at all: a loop test validated its shape and dropped it.
• "What it is made from" draws the provenance field as a map. A source selector isolates one contribution or shows whichever dominates each cell; a depth control walks the water column; the readout follows the pointer and the arrow keys; a cell opens into its full stacked profile. The analyst has published that field since feature 116. What is genuinely blocked is far narrower than the region: FR-122's per-source rays, because the analysis kernel reports the gain's row sum and discards its columns. That is said inside the region, beneath the reading.

Both regions read the query layer and the wire the way an external client would — an EDR area query for the field, position queries for a column — and the shell holds no private route to the store.

The centre region's first build was a grid of grey buttons over a list of four percentages, and being dull was a correctness problem rather than a matter of taste. The interesting fact in the provenance field is spatial: the measurement share is a footprint, bright where a sensor reached and dark where the analysis had only its background, and it shrinks with depth. Four numbers for one column cannot show a footprint. The palette is computed rather than chosen — four sources, fixed order, never cycled, validated against this shell's own surface #10151b, with the worst adjacent pair at ΔE 8.4 under protanopia, which is over the floor and close enough to it that the per-source hatch, the legend, the words and the printed figures are obligatory rather than decorative.

The instance, opened at the change

https://deepbluecltd.github.io/drogna/instances/claude-srd-model-forecast-specs-ws9x3d/#/view/forecast

Set the clock to ×60 or ×600 in the header. The gauge decays, the timeline fills, a hold appears with its shortfall in ticks, the right region fills with the features and their widening rings, and the centre region comes up as a field: amber where the model made the background ocean, blue where the archive did, and a green patch where the sensors actually reached. Switch to measurement to isolate that footprint, walk the depth row to watch it shrink, and click a cell for its column.

The blog entry

https://github.com/DeepBlueCLtd/drogna/blob/claude/srd-model-forecast-specs-ws9x3d/site/docs/blog/posts/affordable-when-you-do-not-need-it-yet.md

The inverted affordability rule, and the becalm that reading it the obvious way produces.

What was watched failing

Every new check, planted and reverted. The stability refusal with its ceiling disabled; the becalm test against the affordability rule read the obvious way round; check-declared-cost against a planted key in the scheduler's master and again in run.json; the whole-feature decline check against a planted rename; the broker conformance check in loop.test.ts; the once-per-episode hold check (201 against 1); the becalm-on-restart test against the restored throw (expected 3 to be greater than 3); the carry-velocity test against the restored inference (expected 7.0028 to be close to 4); the uncertainty-growth assertion against a carry that does not widen; the features subscription with its payload dropped; the feature restatement removed; the standing declaration removed; the share field asserted to vary, against a slab read off a fixed index (expected 1 to be greater than 1); the depth control asserted to re-read, against depth dropped from the effect's dependencies.

Three of those were checks I had written that could not fail, and three more failed for the wrong reason. Same shape each time — an assertion placed where the thing it tests cannot yet have gone wrong, or measured along the wrong axis:

• the becalm-on-restart test's first two drafts both passed against unfixed code. One restarted the scheduler during the first run, and a restarted scheduler counts run ids from zero again — so it asked for the id already occupying and was rescued by the collision rather than by anything being right. The other asserted that a request followed the restart, which a becalmed loop also does: it makes exactly one;
• the carry test asserted to 0.0005 km/day and failed on a lat/lon round-trip while the planted fault went unremarked;
• the uncertainty-growth assertion gathered every ring in the plot and required the largest to exceed the smallest — true of any two different features at the same lead. Planted against a carry that does not widen at all, it passed.

The depth-control assertion compares the z of the first and last area query rather than counting them, for the same reason: a control that re-rendered without re-reading would grow the count while fetching the same slab for ever.

All of it is in specs/123-forward-step/tasks.md (T049–T094).

Backend changes: what was brought up, and what was seen

Not a backend change in the services//deploy/ sense — drogna V2 runs entirely in the browser.

At this head: 684 app tests, 40 script tests, 22 gates, all six capture proofs, and the Forecast tab measured in a browser at 390px and 360px with the loop warmed — nothing scrolls sideways, every control clears the 44px thumb floor.

Two gaps in the checks, both found the hard way.

pnpm check is not the build. Every check on this branch reported green while every CI run failed — seven of them — because CI runs six capture proofs after the checks and CLAUDE.md said pnpm check was "what CI runs". Corrected in this diff.

And capture:mobile pins the clock to rate 0 before it measures, so every surface drawn from an announcement is absent from every picture it takes. Claiming "the narrow presentation holds" from that proof is an empty claim for anything the loop produces. Measured properly: .forecast-gauge-bar had been scrolling sideways at 17px of content in a 14px box since the day it was written, and this round the region overflowed by exactly two pixels from a width: 100% map with a 1px border under content-box. Both gaps are reported rather than closed — a gate asserting that every capture:* script appears as a CI step, and a proof that warms before measuring, each belong in a change of their own.

Left undone, and why

• Feature 124's volume and per-source rays. The rays are blocked on the analyst, not on drawing: FR-122 wants one ray per source at a width proportional to its contribution, and the analysis kernel discards the per-source columns before anything could draw them. specs/124-forecast-illustration/tasks.md carries T001–T035; its FR-05 is amended to record that the plan view of the tracks landed here.
• The shipped forecast horizon is 45 minutes, and the drawing makes that visible. Four steps of fifteen minutes: each feature moves ~0.2 km over the horizon while its uncertainty grows from 24.5 km to 49.1 km, so the claim is some two hundred times wider than the motion it predicts. SRD FR-113 says the purpose is "a falsifiable claim about next week". One of the requirement and the configuration is wrong; establishing which is a requirements decision, and changing steps/step_seconds moves snapshots, costs, validity and much of the suite. Raised, not acted on.
• The front's published bearing uncertainty is 20–80× its measured error. Over-stated, which is the safe direction for Constitution IX, but nothing the estimator could plausibly publish would falsify it.
• A restarted scheduler reuses run ids, so a publication can clear the wrong outstanding run by collision. Benign today; not benign once anything correlates a request with the publication that answered it.
• Leakage tripwire Open question: leakage mask-scoring gate needs a quieter kernel #57 is left at empty-mask, with the measured cause recorded (byte-identical analyses, digest 057e83baae65) and the deeper mechanism stated as unsettled rather than closed by a bound.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_013Yhrus4EAa9MHMbbSuzMhc

[github-actions]

This branch, running: https://deepbluecltd.github.io/drogna/instances/claude-srd-model-forecast-specs-ws9x3d/

Intro · Background · Data · Operator · Forecast · Map · Messages · Sampling · Courses · Feasibility

Built from dec1253946cce3d3c2c8474e09a09201ea0a4b30, and replaced in place by every further push to this branch. Synthetic throughout, as the header says.

[IanMayo]

Two independent adversarial passes read this diff without having seen it written, and every finding was verified against head before it was posted. The two serious ones are fixed in this branch; what is inline here is what was deliberately left, with the reason.

The assumptions worth checking first

Ranked by how much breaks if the assumption is wrong.

1. A run may occupy ticks, and every way that window can strand the loop is enumerated. It was not. The diff answered one entrance — the runner stopped mid-occupancy — and asserted the other could not be reached. Restarting the scheduler reaches it. Fixed: the runner publishes run-failed for the run it refuses instead of throwing into a broker handler that catches and counts.
2. Features are carried at the velocity the field is carried at. They were not, for shift-advect-v1: the selector was the presence of a parameter block the runner always populates, so the branch was taken always. Fixed: the kernel is asked, through an optional port member alongside subStepsPerStep.
3. The cost declared at a nominal cell is the cost the run occupies. Holds, and a test compares them — but both figures are 1 and stay 1 for any cell above ~0.57 km. See the check-declared-cost comment.
4. The scheduler may derive tick length from consecutive clock samples. Sound: remainingValidityTicks() fails open on a missing forecast, a lapsed one, and an underived tick length alike.
5. The second kernel's distinguishing behaviour is visible at the shipped configuration. Measured at 0.019 °C against 0.35 °C of noise — see the kernel.ts comment.
6. The uncertainty beside a feature describes that estimator's accuracy. Not for the front's bearing — see the features.ts comment.

Confirmed and fixed in this branch

• the becalm through a scheduler restart (above);
• the carry velocity (above);
• the analyst hook budget, which this feature made 38% dearer — 3609 ticks to 4429, 28.0 s to 38.7 s — walking into its ceiling one commit at a time: 52.8 s, 57.5 s, 59.96 s, timeout;
• eleven narrow-presentation failures, which CI had been reporting on every push while pnpm check reported green.

Confirmed and deliberately left

Four inline comments: the front's bearing uncertainty, the run-id collision across a scheduler restart, the shipped configuration's physics against its noise, and check-declared-cost's line attribution.

Checked and sound

22/22 gates including all three drift gates, with the generated output a genuine regeneration. pnpm replay-proof holds — AT-04 survives the second kernel and the held publication. No new wall-clock read in operational code and no new harness:allow-wallclock marker. No import across the seam. Math.random() only in test client ids. The published features meet the estimator bounds at four shipped seeds — eddy centre 4.3–30.0 km against radii of 51.8–66.4 km, front anchor 0.4–8.1 km across the authored line against 30 km sharpness — with the fifth seed declining, with its reason on the wire. check-declared-cost fires on a planted violation in a copy of the real tree, not only against its stub fixture, and both arms fire. The monitor's streak refactor is behaviour-preserving. app/public/snapshots/ is untouched and correctly so.

A gap in the gates, which is the most useful thing here

There is no gate for what CI's capture proofs check, and no gate that the two are the same set. This branch shipped seven consecutive red CI runs while pnpm check reported green on every commit, because check does not run them and CLAUDE.md said it did. The line is corrected in this diff, but a corrected sentence is weaker than a check: a gate asserting that every capture:* script in package.json appears as a step in ci.yml — the same shape as check-gate-registry's "an unregistered gate is a gate that never runs" — would make the drift impossible instead of merely documented. Not added here, because a gate is a line appended to a registry and belongs in a change of its own.

Reviewed with two passes on Claude Opus 5, one for correctness and one for simplicity and the record, with every finding verified against head before posting.

---

Generated by Claude Code

[IanMayo]

The front's published bearing uncertainty is 20–80× its measured error, and nothing could falsify it.

Measured on the published ctl/forecast/features message at four shipped start-condition seeds, scored against the manifest:

seed	bearing error	published uncertainty.bearing_degrees
1180001	0.5°	38.3°
1180002	2.6°	40.5°
1180003	0.2°	41.6°
1180004	0.9°	37.5°

Mechanism: uncertaintyFor(front.anomalyStepC, cellKm) gives the front a scale of one grid cell, and bearingDegrees = atan2(positionKm, max(radiusKm, 1e-6)). Once analysisErrorC ≳ anomalyStepC the positionKm clamp binds and the ratio approaches 1, so the figure saturates at 45° at lead 0 and up to 63° at lead 3. On a bearing folded into 0–180°, ±40° is close to a uniform claim.

This is an over-stated uncertainty, which is the safe direction for Constitution IX — it is not the "soften a bound until it passes" fault. But FR-113's stated purpose is that a forecast makes a falsifiable claim about next week, and this quantity does not: nothing the estimator could plausibly publish would falsify it.

The real accuracy comes from averaging thousands of gradient cells in doubled angles — the finding T052 was written for — and the uncertainty model knows nothing about that averaging. Left unfixed deliberately: the fix is a model of that averaging (the standard error of a circular mean over N cells), and choosing it is a judgement about what the published figure is for, which belongs with a reader rather than with me at the end of a long branch.

---

Generated by Claude Code

[IanMayo]

A restarted scheduler counts run ids from zero again, so a publication can clear the wrong outstanding run.

Found while writing the becalm-on-restart test, not by looking for it — and it is the reason two drafts of that test passed against unfixed code.

inFlight is cleared by identity: if (published.run_id === this.inFlight) this.inFlight = undefined. A fresh scheduler restarts its counter, so it issues …-run-0 again. If the run still occupying its cost is …-run-0 — which it is whenever the restart lands during the first run — then that older run's publication matches the new scheduler's outstanding id and clears it. The loop keeps turning, but for the wrong reason: two different runs shared a name.

It is currently benign, because the only path that reaches it now ends with the loop turning anyway. It stops being benign the moment anything downstream correlates a request with the publication that answered it — which is exactly what the Forecast timeline does, keyed on run:${id}, and what feature 124's provenance work will do.

Not fixed here: the fix is a scheduler-lifetime discriminator in the run id (or seeding the counter from what the store already holds), and it changes an id that appears on the wire, in the store, and in every committed snapshot. That is a change worth making on its own, against its own drift-gate run, rather than folded into this branch's sixth round.

---

Generated by Claude Code

[IanMayo]

The physics this ADR was written for is 5% of one noise draw, and nothing on disk says so.

Measured over a whole run at the shipped configuration — 3 integration steps, 2700 s, noise off, on the 96×80×6 grid:

• maximum change to the temperature field: 0.019 °C, against a model-noise standard deviation of 0.35 °C per step and a 2.5 °C blob;
• the eddy moves 0.22 km — 4% of one cell;
• the layers' shear over the run: ~0.06 cells.

The published forecast is, to a first approximation, the analysis plus noise. kernel.test.ts's shear assertion is real, but it passes on a toy grid with twice the velocities and ten times the relative displacement, so it does not establish that the distinguishing behaviour is visible at the configuration that ships.

Related, and in the same measurement: the scheme's own numerical diffusivity is uΔx(1−C)/2 = 196 m²/s east and 97 m²/s north here, against a configured horizontal_diffusivity_m2_per_s of 45. The explicit term is a minority contributor by 2–4×, and the master describes it as "explicit horizontal diffusivity, applied per layer" without saying so — a reader tuning that number is tuning the smaller half.

Neither is a fault in this diff: the kernel is correct, the configuration is the one that was asked for, and ADR-0042's argument for a second implementation stands. Both are facts about the shipped configuration that a reader of the ADR would reasonably expect to find stated and will not.

---

Generated by Claude Code

[IanMayo]

lineOf(lines, key) returns the first line in the whole file containing "key".

So where a key name appears under two components, the finding points a reader at the wrong one. The gate still fires correctly — this is only the line number it reports — but a gate that names the wrong place is a gate someone will argue with, and both arms were watched failing on the strength of finding the right one.

Minor, and not fixed here because the fixture that would prove the fix needs two components sharing a key name, which the real tree does not currently have.

Two smaller notes in the same class, from the same pass:

• carryFeatures carries eddy, moving and front through three near-identical spread-with-IIFE blocks, and featureStep builds four near-identical objects each closed with as ForecastFeaturesFeature. Those four casts defeat the generated discriminated union: a misspelled parameter key would compile, and only loop.test.ts's runtime validation would catch it.
• sub_steps_per_step is 1 at both the nominal and the real cell and stays 1 for any cell above ~0.57 km, so the check comparing declared against reported has a reachable failing state only after a ~10× grid refinement. tasks.md records this honestly as headroom — worth knowing that it is not what would have caught the 11 km → 5 km nominal-cell correction the record credits it near.

---

Generated by Claude Code