Size: M | Domain: platform
Problem
Nothing validates the extension's boot path. C1 startup / custom traces in the evidence catalog measures how long startup takes; nothing checks that it happened in the right order, that split init scripts ran in the declared sequence, or that a change to app/scripts/load preserved the contract.
MV3 makes this load-bearing. The service worker is evicted and restarted constantly, so the boot path runs far more often than a page load ever did, and a reordering that appears harmless in a warm session surfaces as a cold-start failure a user cannot reproduce.
extension-lifecycle-decoupling (#44) documents the lifecycle and corrects the assumptions people make about it — no onSuspend lock handler, alarms-based timers surviving restart, state persisted in chrome.storage.session. What it cannot do is prove a given boot path is intact after a change.
Solution
An engine skill that proves a boot-sequence claim, in the shape the catalog's other engines use.
The falsifier is the whole problem here: a boot assertion satisfied by a warm start, where the phase under test never ran. That failure mode is silent and reads as a pass, exactly like the vacuous-green cases falsifying-test exists to catch. So the skill's first obligation is proving the cold path was actually exercised before interpreting any assertion.
Scope to cover:
- Init-script order, against the declared sequence rather than against whatever ran
- Cold start distinguished from warm, with the distinction asserted, not assumed
- What must be available by the end of each phase, and what must not be touched before it
- Behaviour across service-worker eviction, which is the common case rather than the edge case
Acceptance criteria
Notes
Fills a genuine hole: of the boot- and build-adjacent lanes, D1, D4, D5, F8, and C1 have no engine skill, and boot order is not a lane at all.
Suited to whoever owns the load path — the recent history there is concentrated in app/scripts/load and the init-script split.
Tracked in Jira as AIENG-94.
Size: M | Domain:
platformProblem
Nothing validates the extension's boot path.
C1 startup / custom tracesin the evidence catalog measures how long startup takes; nothing checks that it happened in the right order, that split init scripts ran in the declared sequence, or that a change toapp/scripts/loadpreserved the contract.MV3 makes this load-bearing. The service worker is evicted and restarted constantly, so the boot path runs far more often than a page load ever did, and a reordering that appears harmless in a warm session surfaces as a cold-start failure a user cannot reproduce.
extension-lifecycle-decoupling(#44) documents the lifecycle and corrects the assumptions people make about it — noonSuspendlock handler, alarms-based timers surviving restart, state persisted inchrome.storage.session. What it cannot do is prove a given boot path is intact after a change.Solution
An engine skill that proves a boot-sequence claim, in the shape the catalog's other engines use.
The falsifier is the whole problem here: a boot assertion satisfied by a warm start, where the phase under test never ran. That failure mode is silent and reads as a pass, exactly like the vacuous-green cases
falsifying-testexists to catch. So the skill's first obligation is proving the cold path was actually exercised before interpreting any assertion.Scope to cover:
Acceptance criteria
app/scripts/loadNotes
Fills a genuine hole: of the boot- and build-adjacent lanes,
D1,D4,D5,F8, andC1have no engine skill, and boot order is not a lane at all.Suited to whoever owns the load path — the recent history there is concentrated in
app/scripts/loadand the init-script split.Tracked in Jira as
AIENG-94.