[frahlg]

This PR is step 6 (PR d) of the fuse-at-rating plan (owner rule of 27 Oct). Each phase's working limit is the fuse rating less safety_margin_a. The margin is opt-in and defaults to 0, and nothing holds amps back below that line.

Final review fix (2b30933b)

Blocking: siterig/short went red at margin 0 on s8-60-25 as well as s18-16, because the rig still judged at fuse - 1 A. This PR now carries #1907's judge hunks (see Change). On this head: make verify clean (Docker unavailable, so the avahi and release-context runs were skipped), go test -race ./internal/control/ ./cmd/ftw/ ./internal/configreload/ and the hygiene scripts pass. siterig/short has not run on this head yet; the runner does that.

Merge order

This PR sits on top of the fuse stack and lands last. Its base is ev-base-after-restart (#1926). Merge in this order:

1. fix(control): car and battery work to the fuse rating (fuse stack #1910, #1891, #1913, #1923, #1924, #1925, #1926, #1914) #1910 b-ev-fuse-line-at-rating: the car's line moves to the rating less safety_margin_a.
2. fix(control): battery fuse guard reads each phase with its direction #1891 a5-battery-fuse-signed-phases: battery relief uses the same line, with no 1 A floor.
3. fix(control): battery fuse cut lands on the line, not half a margin below #1913 c-battery-fuse-no-buffer: the battery cut lands on the line.
4. fix(control): a landed EV cut covers nothing later; a raise that no longer fits comes off #1923 ev-cut-landed-and-unshown: a cut the meter already shows covers nothing later.
5. fix(control): a battery charge rise fits each phase before it is sent #1924 battery-rise-per-phase-cap: a battery charge rise fits each phase before it is sent.
6. fix(control): the car comes before battery charge #1925 car-before-battery-charge: the car comes before battery charge.
7. fix(control): after a restart the battery credits the car the meter shows #1926 ev-base-after-restart: after a restart the battery credits the car the meter shows.
8. This PR.

Two PRs off master must land before this one:

• fix(control): read a whole-ampere meter's phase current from its power #1932 whole-amp-phase-current: Core reads a whole-ampere meter's phase current from its power. Without it, margin 0 lets a phase sit up to 1 A over In on many P1 meters (see Risk).
• fix(drivers): bound driver_init and apply fuse settings before reload #1893 has already landed (573d24f). It moved the config-reload block out of main.go into configreload.Apply. The stack now holds master (77b15c2), and this PR carries the new comment in configreload/apply.go.

#1907 need not land first: this PR carries its judge hunks (see Change).

When this PR is retargeted and origin/master is merged in, go/cmd/ftw/main.go conflicts in the reload block. Take master's side: this PR's only main.go change is a comment in that block, and the block now lives in go/internal/configreload/apply.go. Then reword apply.go's "nil → 0.5, explicit 0 → disabled" (line 88 on master) to "nil → 0 (work to the fuse rating), an explicit value wins". Review's trial merge on a5cdeae, with master's main.go taken, builds, vets, and passes go test on cmd/ftw, configreload and config.

In the same retarget merge, add the reload-path test below as go/internal/configreload/apply_fuse_margin_test.go. It cannot land before then: this branch has no configreload package, and its reload block is a closure inside main(). Without it, a hidden 0.5 A default put back on reload passes every suite (review's mutation, after ctrl.SiteFuseSafetyA = newCfg.Fuse.EffectiveSafetyMarginA(): if newCfg.Fuse.SafetyMarginA == nil { ctrl.SiteFuseSafetyA = 0.5 }). I checked it on a copy of master (573d24f) with DefaultFuseSafetyMarginA = 0: it passes under -race, and with that mutation in apply.go it fails with "margin after reload = 0.5 A, want 0 A". It also fails if the reload stops setting the margin, since Core starts at 0.5 A.

apply_fuse_margin_test.go

package configreload

import (
	"sync"
	"testing"

	"github.com/srcfl/ftw/go/internal/config"
	"github.com/srcfl/ftw/go/internal/control"
)

// A reload with no fuse.safety_margin_a works to the fuse rating, the same as
// startup; an explicit margin still wins. Core starts at 0.5 A so a reload
// that leaves the old value in place, or puts a hidden default back, fails.
func TestApplyUnsetFuseMarginReloadsAsZero(t *testing.T) {
	half := 0.5
	for _, tc := range []struct {
		name   string
		margin *float64
		want   float64
	}{
		{"unset", nil, 0},
		{"explicit 0.5 A", &half, 0.5},
	} {
		t.Run(tc.name, func(t *testing.T) {
			var cfgMu sync.RWMutex
			var ctrlMu sync.Mutex
			cfg := &config.Config{}
			cfg.Fuse.MaxAmps = 16
			cfg.Fuse.Voltage = 230
			cfg.Fuse.Phases = 3
			cfg.Fuse.SafetyMarginA = &half

			ctrl := control.NewState(0, 50, "meter")
			ctrl.SiteFuseSafetyA = 0.5

			newCfg := *cfg
			newCfg.Fuse.SafetyMarginA = tc.margin
			Apply(&cfgMu, cfg, &ctrlMu, ctrl, &newCfg, nil)

			if ctrl.SiteFuseSafetyA != tc.want {
				t.Fatalf("margin after reload = %v A, want %v A", ctrl.SiteFuseSafetyA, tc.want)
			}
		})
	}
}

When each PR squash-merges, move the next one's base to master, then merge origin/master into it and push. The push matters: see "CI on the stack" below.

Land #1910 and #1891 close together. On #1910 alone the rig's siterig/short fails s18-16 ("battery yields before the minimum-step car"); it passes on master and on #1891 and everything above it.

Sync (28 Oct, 09:00)

#1913 gained 358da3b at 08:01 (a test only: the battery beside a minimum-step car holds the fuse line, rig s18-16). I merged it up the stack, each step a plain merge with no conflict, pushed fast-forward:

PR	Branch	New head
#1923	ev-cut-landed-and-unshown	a059b6a
#1924	battery-rise-per-phase-cap	48fb649
#1925	car-before-battery-charge	5c9c336
#1926	ev-base-after-restart	b82e44d
#1914	d-fuse-margin-default-0	0befc58

TestBatteryBesideMinimumCarHoldsTheFuseLine passes at each step. At margin 0.5 A (#1923 to #1926) the battery holds 4473..4485 W and the peak phase is 15.59 A. On this branch, at margin 0, it holds 4818..4830 W, drops 4824 → 4756 W across the house step, and the peak phase is 16.09 A.

This branch now holds the current tips of #1910 (ddab122), #1891 (b36e951), #1913 (358da3b), #1923, #1924, #1925 and #1926, plus master through 7840c33. git branch -r --merged HEAD lists every stack branch.

The earlier sync (28 Oct, morning) merged ev-base-after-restart at 551febd. Only #1910's changeset conflicted. The merge kept #1910's new sentence on an offline battery's relief and kept "a 0.5 A margin" in place of "the default 0.5 A margin".

The earlier restack (28 Oct, night) merged #1891's tip up the stack. Only #1924 conflicted, in dispatch.go. The merge kept signedPhasesA, dropped signedA, and replaced phaseMoveW with phaseSample.moveW. The merge commit e2faf1e explains the resolution.

Problem

An unset fuse.safety_margin_a resolved to 0.5 A. Every line built on it sat 0.5 A per phase (345 W on 3 × 230 V) under the fuse, though nobody had asked for a margin. That covered the car's and the battery's per-phase line (after #1910 and #1891) and the aggregate ceilings: the guard, the joint EV/battery allocator, the PV export guard and the peak-limit ceiling. The settings form showed 0.5, and its help promised headroom. The peak-limit error always named "a 0.0 A safety margin", even when there was none.

This PR was first blocked: on #1910 alone, margin 0 made TestSiteSimRandomHouse/1 fail. An EV cut the meter already showed kept covering a later house step, so Core cut one step and stopped. #1923 fixes that, and seed 1 passes on this branch.

Change

• go/internal/config/config.go: DefaultFuseSafetyMarginA = 0. The pointer stays, so any explicit value, 0 included, still wins. The field and resolver comments say the margin is opt-in.
• Stored configs (owner decision): FTW keeps every explicit value. When the loaded value is exactly 0.5 A, loading adds one notice on the retired-setting channel (c.Retired, logged once at startup): "fuse.safety_margin_a is 0.5 A, FTW's old default. FTW now works to the fuse rating. Set 0 to use it." Both load paths (YAML and stored settings) do this. It changes no stored state, and DropRetiredSettings leaves the value alone.
• go/internal/control/dispatch.go: the peak-limit error names the margin only when it is above 0. The SiteFuseSafetyA comment now says the margin is opt-in and zero is the default.
• go/cmd/ftw/control_state.go, go/internal/configreload/apply.go: the "nil → 0.5" comments now say nil → 0. fix(drivers): bound driver_init and apply fuse settings before reload #1893 moved the main.go comment into configreload/apply.go.
• web/settings/tabs/control.js: the field shows 0 when unset. New help: "Optional. Amps to keep below the fuse rating, for an inverter whose own phase limiter trips at the rating. 0 works to the rating."
• Site sim: simFuseSafetyA = 0, the new default. fitScenario takes the room under the line and sets the house from simFuseSafetyA, so its "exact fit" cases stay exact at any margin. The "charger's own load balancer" scenario passes at margin 0 only because the balancer sits at 25 A, which is the rating and so the new line. The Core bug remains: a cut comes off an offer the car does not draw (stepEVMeterLimit). Two known variants keep it tracked and turn red once someone fixes it: the stored 0.5 A margin, and a balancer at 25.5 A at margin 0.
• Rig s18 (go/test/site/ev_battery_priority_test.go): "own commands stay inside the rated fuse" now skips the 10 s after the house's 0.1 A step, the same gap the scenario's minor window leaves. At margin 0 Core holds the phases at 16.00 A, so that step lands over the line until Core cuts. On fdfbfec siterig/short failed s18-16 on this criterion (and s8-60-25, see the next item): the phase read 16.101 A for 3 s right after the step, and Core cut the battery 4851 → 4719 W within 2 s. The owner's rule judges an overage between In and 1.2 × In by the I²t model, and "fuse holds" still covers it. On that run's record Core's own commands peak at 16.008 A before the step and 16.005 A after it, inside the 16.01 A bound. A new metric, max_i_own_commands, reports that number beside the old one.
• Rig judges, ported from test(site): the rig judges "over the limit" above the fuse #1907 (go/test/site): s3, s8, s9-s11 (overage()), s15bat and the random invariants now count time over the fuse rating, not over fuse - 1 A. At margin 0 the car in s8-60-25 settles at 25 A, the rating, and the old judge counted 271 s above 24 A against 67 s allowed (fdfbfec: over_fuse_longest_s 0, fuse_blown false). The hunks match test(site): the rig judges "over the limit" above the fuse #1907's, so test(site): the rig judges "over the limit" above the fuse #1907 merges cleanly after this.
• Changesets (patch): d-fuse-margin-default-0.md says what moves once the stack has landed. On a site with no saved margin, the car, the battery's charge and fuse relief, and the fuse's total import and export ceilings each move up 0.5 A per phase, to the rating. The hourly import_limit does not move. In fix(control): car and battery work to the fuse rating (fuse stack #1910, #1891, #1913, #1923, #1924, #1925, #1926, #1914) #1910's changeset, "with the default 0.5 A margin" now reads "with a 0.5 A margin".

Tests

• TestFuseSafetyMarginNilUsesDefault: an unset key resolves to 0.
• TestFuseSafetyMarginLoadKeepsExplicitValues: unset gives 0 with no notice. Explicit 0, 0.4 and 1.2 stay, with no notice. Explicit 0.5 stays 0.5, with exactly one notice.
• TestStoredOldDefaultFuseMarginIsKeptWithANotice: a 0.5 A margin in state.db keeps steering the site over two loads. It gives one notice per load, survives DropRetiredSettings and stays in the stored document.
• TestUnsetFuseMarginReachesCoreAsZero (cmd/ftw): a config with no safety_margin_a reaches Core as 0, a peak limit at the fuse (43470 W on 63 A × 3 × 230 V) is accepted and 1 W more is refused, and an explicit 0.5 A reaches Core as 0.5 A. Review showed that a mutation restoring a hidden 0.5 A default at startup (if cfg.Fuse.SafetyMarginA == nil { ctrl.SiteFuseSafetyA = 0.5 } after EffectiveSafetyMarginA) passed every suite. This test fails on it: "unset margin reached Core as 0.5 A, want 0".
• Reload path: no test on this branch; see Merge order for the configreload test that lands with the retarget.
• TestS8JudgesAtTheFuse (new) and test(site): the rig judges "over the limit" above the fuse #1907's TestInvariantsJudgeAtTheFuse (go/test/site, no simulator): a phase at exactly the fuse passes; 0.1 A over it past the time budget fails. Both fail on the old judges ("a phase at exactly the 25 A fuse failed").
• TestS18OwnCommandsSkipTheHouseStep (go/test/site, runs without a simulator): 4 s at 16.1 A right after the house's step passes; the same 4 s at 50 s or 150 s, with no outside step, fails. Before the judge change it failed with "4 s at 16.1 A right after the house's step failed".
• TestSetPeakLimitMessageNamesOnlyARealMargin: with 0.5 A the error names the margin. With 0 it names none, and the fuse itself (11040 W) is the ceiling.
• Site sim at margin 0: #1761 replay, safety_margin_a 0.5 A keeps the old value covered as an opt-in.
• TestSiteSimCarEndsAtTheLine: with the old fitScenario at margin 0 it fails (car 8280 W ... want 8625 W), because a 3.5 A house leaves 12.5 A of room, not twelve whole steps. With fitScenario reading simFuseSafetyA, it passes, and the car ends at 8280 W on the 16 A line.
• TestSiteSimScenarios: the load-balancer scenario at 25 A passes at margin 0. Its two known variants fail as known: at 0.5 A with "over Core's limit for more than 11s (heat 24.6 A, limit 24.5 A)", and with the balancer at 25.5 A with "(heat 25.1 A, limit 25.0 A)".
• On 0befc58 (the sync merge), make verify exits 0 with its Docker steps skipped, go test -race -count=1 ./internal/control/ passes (223 s), and the hygiene checks against origin/master (573d24f) find no planning documents, 133 telemetry reads with none added, and no new legacy brand copy. On dbc4332 (the head) go vet and go test -race -count=1 ./test/site/... pass and the hygiene checks give the same result.
• On fdfbfec, go test -race -count=1 passes on ./cmd/ftw/ and ./internal/config/, make verify exits 0, and the hygiene checks against origin/master (573d24f) find no planning documents and 133 telemetry reads, none added.
• On a5cdeae, go test -race -count=1 passes on ./internal/control/, ./cmd/ftw/, ./internal/config/, ./internal/configreload/, ./internal/api/, ./internal/loadpoint/ and ./internal/telemetry/.
• make verify is clean on the synced head. Its Docker steps skipped (no daemon).
• node --test 'web/**/*.test.mjs' (the CI web job): 893 of 893 pass.
• The repo-hygiene checks, run by hand against master (7840c33) for the whole stack: no planning documents added; telemetry reads outside go/internal/telemetry go from 134 to 133, with no file adding one; no new legacy brand copy; both helper unit suites pass.
• Not run here: TestSite / siterig. The runner on macmini runs those.
• The settings field still needs a human look in a browser.

200-seed count

This is TestSiteSimRandomHouse's random house: 200 seeds, 1 h each, on the sync merge b621bab. Review reran it on fdfbfec and got the same counts and seeds. Since then this branch gained only tests (358da3b and the s18 judge). It uses review's harness. The "step judge" restarts the over-limit allowance at each outside step, as #1920 (triage R2) does for the rig.

House drawn up to	Margin	Plain judge	Step judge
line (In − margin)	0	6	0
line (In − margin)	0.5 A	5	0
In	0.5 A	87	not run (the house alone passes the line)

Before the sync (4ecebfd) the counts were 7, 5 and 86. Seed 172 now passes at margin 0.

Plain-judge failures. At margin 0 these are seeds 70, 99 (twice), 138, 158, 179 and 189. At 0.5 A they are 138, 172, 179, 189 and 198. Each one has the same cause:

• The charger has a 40 s delay.
• Core cuts within 1 to 3 s of the heat crossing the line.
• A second house step lands inside the same run, and Core cuts to 0 W within 1 to 2 s of that step.
• The 40 s charger applies that last cut after the 46 s allowance, which the plain judge counts from the first crossing.

The step judge counts none of them.

The house-at-In row. 87 seeds fail:

• 81 seeds: the house alone. Every failure has the car offered 0 W and drawing 0 W. The house alone holds a phase over the line.
• Seeds 103, 161, 172 and 189: the 40 s judge case above. The offer is 0 W and the car still draws until its cut lands.
• Seed 110: two phases cross at different times. Phase 3's heat crossed the line first, and Core cut 2 A for it. Phase 1 (28.6 A) crossed 16 s later, and Core cut again. The 40 s charger applied the second cut after the allowance, which ran from phase 3's crossing. Core cut each phase when that phase's heat crossed, as the I²t rule asks.
• Seed 69: a real Core fault, not new in this stack. Core cut the car 9 to 6 A in the same second that a house step raised phase 3 by 2.5 A. The meter then showed phase 3 at 26.5 A, 0.5 A below the reading the cut was sent for. To Core, the cut had not landed. The sim's charger declares no power_max_age_s, so Core waits evUnknownSettle (3 min) for it to show. For those 3 min Core held the car's 6 A minimum, with the phase at 26.5 A on a 25 A fuse and the heat rising to 26.2 A. A targeted reproduction (a house step on every phase in the same second as the cut) does the same at margin 0, on this branch and on master alike: 3 min over the line, heat 26.8 A. With a declared 5 s or 40 s charger delay the hold is 23 s or 43 s, the time Core gives the charger. It is not fixed here. EV fuse cut: a house step in the same second hides the cut's landing, and Core holds a phase over the line for evUnknownSettle #1931 tracks it, for a fix in ev_fuse_budget.go (unshownOrders, cutForA) before stable.

CI on the stack

GitHub's required check is go test + vet, the aggregate job in test.yml. test.yml, repo-hygiene.yml, changeset-check.yml, brand-cleanup.yml, core-binaries.yml and history-converter.yml run only on PRs into master. native-solver.yml runs on any PR that touches its paths, and the macmini runner posts siterig/short on stacked heads.

As GitHub showed it at 09:00 on 28 Oct, after the sync pushes:

PR	Base	Head	Has run	Has not run
#1910	master	ddab122	all of the above; siterig/short fails s18-16	—
#1891	#1910	b36e951	siterig/short pass	go test + vet and its suites, repo hygiene, changeset, brand, Core binaries, history converter
#1913	#1891	358da3b	siterig/short pass	same
#1923	#1913	a059b6a	nothing yet (the old head 8a10b27 passed siterig/short)	same, plus siterig/short
#1924	#1923	48fb649	nothing yet (19d8a29 passed siterig/short)	same, plus siterig/short
#1925	#1924	5c9c336	nothing yet (3623603 passed siterig/short)	same, plus siterig/short
#1926	#1925	b82e44d	nothing yet (551febd passed siterig/short)	same, plus siterig/short
#1914	#1926	dbc4332	nothing yet. fdfbfec passed native-solver; its siterig/short failed s18-16 on "own commands stay inside the rated fuse" (see Change)	same, plus siterig/short

The sync heads differ from the passed ones only by 358da3b, a test file in go/internal/control.

test.yml and the other master-only workflows listen for opened, synchronize and reopened. Moving a PR's base to master starts none of them. Each PR needs a push after the retarget, which merging origin/master provides. The local runs above (race tests, make verify, web tests, the hygiene checks) cover the whole stack's code on this branch. They do not stand in for the required check on each squash commit.

Risk

Medium. On sites with no saved key, which is every rig run and most sites, every line moves up 0.5 A per phase together. An inverter whose own phase limiter trips at the rating may now cut to 0 W. That is why the old default existed, and the opt-in margin is the remedy. Watch for it on the validation sites during the beta. Sites with a stored 0.5 A keep it and see one startup notice. No new control mechanism, and no dead zone or timer moves.

With Core at the line, any house rise puts a phase over In until Core cuts. On rig s18-16 a 0.1 A step read 16.10 A for about 3 s. The I²t rule allows that, and the s18 judge now says so (see Change).

At margin 0, a whole-ampere meter has no cushion either. Many P1 meters (p1_dsmr, zuidwijk_p1) report phase current in whole amperes, and Core read magnitude from l*_a alone. Review measured a phase at 16.60 A (truncating) and 16.45 A (rounding) on a 16 A fuse for 20 min at margin 0, against 15.60 A and 15.45 A at 0.5 A. #1932 reads each phase as at least its power over its measured voltage. On this stack with #1932, the same probes end at 15.60 A and 15.45 A at margin 0, with no time over In. Land #1932 first.

At margin 0, a frozen site meter has no 0.5 A cushion. #1921 (C5, frozen meter counts as stale) is independent, with base master, and touches main.go and dispatch.go away from this PR's lines. It should reach the same beta as this PR or an earlier one.

Related open PRs

• fix(control): a site meter that repeats one reading counts as stale #1921 (frozen-site-meter-stale): see Risk.
• test(site): the rig expects the room the fuse rating gives #1908 (e2) pins safety_margin_a: 0 in the rig. After this PR that pin is the default, so test(site): the rig expects the room the fuse rating gives #1908 stays correct.
• fix(control): fuse protection as one function #1789, fix(control): phase current takes its direction from the phase's power #1782 and fix(control): reserve EV demand until offered power is delivered #1763 change sitesim_test.go from master, outside this stack. Whichever lands later needs a merge there.
• fix(drivers): bound driver_init and apply fuse settings before reload #1893 has landed; see Merge order for the retarget merge.
• fix(control): read a whole-ampere meter's phase current from its power #1932 (whole-amp-phase-current): lands before this PR; see Risk.
• EV fuse cut: a house step in the same second hides the cut's landing, and Core holds a phase over the line for evUnknownSettle #1931: the masked-cut fault behind seed 69.
• test(site): the rig judges "over the limit" above the fuse #1907 changes the rig's judges to the fuse rating; this PR carries the same hunks for s3, s8, s9-s11, s15bat and the invariants. test(site): the rig expects the room the fuse rating gives #1908 and test(site): judge random runs by rig items R2-R7 of the 27 Oct triage #1920 change other parts of the judge.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-27T18:06:42.941763Z	fab8f6f	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.