instar 1.3.1195 → 1.3.1196
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/data/standards-guard-index.json +1 -1
- package/dist/data/standards-guard-index.meta.json +2 -2
- package/dist/data/standards-registry.meta.json +1 -1
- package/package.json +1 -1
- package/src/data/builtin-manifest.json +2 -2
- package/src/data/standards-guard-index.json +1 -1
- package/src/data/standards-guard-index.meta.json +2 -2
- package/src/data/standards-registry.meta.json +1 -1
- package/upgrades/1.3.1196.md +32 -0
- package/upgrades/mirror-staleness-is-not-an-aliveness-fact.eli16.md +35 -0
- package/upgrades/side-effects/mirror-staleness-is-not-an-aliveness-fact.md +78 -0
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
"schemaVersion": 1,
|
|
3
3
|
"generatedFrom": "source-tree",
|
|
4
4
|
"registrySha256": "8e6606a6722433c5ffc15b3870402283c5406083a14cdbd0e18e735731e2aae2",
|
|
5
|
-
"packageVersion": "1.3.
|
|
5
|
+
"packageVersion": "1.3.1196",
|
|
6
6
|
"guards": [
|
|
7
7
|
{
|
|
8
8
|
"ref": "docs/audits/phase-b/f10-triage.md",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"sha256": "
|
|
2
|
+
"sha256": "245d913df7c5e45424a2491bef4d7ea849d2cce4e224a0ab1943fa31195ec96d",
|
|
3
3
|
"registrySha256": "8e6606a6722433c5ffc15b3870402283c5406083a14cdbd0e18e735731e2aae2",
|
|
4
|
-
"packageVersion": "1.3.
|
|
4
|
+
"packageVersion": "1.3.1196"
|
|
5
5
|
}
|
package/package.json
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"$schema": "./builtin-manifest.schema.json",
|
|
3
3
|
"schemaVersion": 1,
|
|
4
|
-
"generatedAt": "2026-08-
|
|
5
|
-
"instarVersion": "1.3.
|
|
4
|
+
"generatedAt": "2026-08-24T02:13:09.489Z",
|
|
5
|
+
"instarVersion": "1.3.1196",
|
|
6
6
|
"entryCount": 202,
|
|
7
7
|
"entries": {
|
|
8
8
|
"hook:session-start": {
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
"schemaVersion": 1,
|
|
3
3
|
"generatedFrom": "source-tree",
|
|
4
4
|
"registrySha256": "8e6606a6722433c5ffc15b3870402283c5406083a14cdbd0e18e735731e2aae2",
|
|
5
|
-
"packageVersion": "1.3.
|
|
5
|
+
"packageVersion": "1.3.1196",
|
|
6
6
|
"guards": [
|
|
7
7
|
{
|
|
8
8
|
"ref": "docs/audits/phase-b/f10-triage.md",
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"sha256": "
|
|
2
|
+
"sha256": "245d913df7c5e45424a2491bef4d7ea849d2cce4e224a0ab1943fa31195ec96d",
|
|
3
3
|
"registrySha256": "8e6606a6722433c5ffc15b3870402283c5406083a14cdbd0e18e735731e2aae2",
|
|
4
|
-
"packageVersion": "1.3.
|
|
4
|
+
"packageVersion": "1.3.1196"
|
|
5
5
|
}
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
# Upgrade Guide — vNEXT
|
|
2
|
+
|
|
3
|
+
<!-- assembled-by: assemble-next-md -->
|
|
4
|
+
<!-- bump: patch -->
|
|
5
|
+
|
|
6
|
+
## What Changed
|
|
7
|
+
|
|
8
|
+
`tests/e2e/benchmark-divergence-alive.test.ts` no longer asserts `mirror.stale === false`. It asserts the wiring facts it owns — the mirror resolves on the production init path, carries a `capturedAt`, and reports a `stale` verdict CONSISTENT with the `staleDays` it computed — and leaves the threshold itself to a unit test with an injected clock.
|
|
9
|
+
|
|
10
|
+
`tests/unit/BenchmarkDivergenceAnalyzer.test.ts` gains that test: with a PRESENT mirror, `capturedAt + 30d` ⇒ `stale: false`, `capturedAt + 31d` ⇒ `stale: true`.
|
|
11
|
+
|
|
12
|
+
No runtime behaviour changes — tests only.
|
|
13
|
+
|
|
14
|
+
## What to Tell Your User
|
|
15
|
+
|
|
16
|
+
None — internal change (no user-facing surface).
|
|
17
|
+
|
|
18
|
+
## Summary of New Capabilities
|
|
19
|
+
|
|
20
|
+
None — internal change (no user-facing surface).
|
|
21
|
+
|
|
22
|
+
## Evidence
|
|
23
|
+
|
|
24
|
+
The shipped baseline `src/data/benchmarkPredictions.json` carries `capturedAt: 2026-07-24T01:20:00.000Z`; `mirrorStalenessMaxDays` defaults to 30. The assertion therefore passed for thirty days and turned RED at 2026-08-24T01:20Z on every branch simultaneously — main included — with no commit involved. Confirmed by running the e2e against `origin/main` at `9f83c19ca`: 1 failed, 4 passed, `expected { present: true, …(3) } to match object { present: true, stale: false }`. It blocked every merge, since `safe-merge` refuses on any red check.
|
|
25
|
+
|
|
26
|
+
Both sides of the boundary are pinned deliberately: a change that made nothing ever stale would satisfy a one-sided test while deleting the signal. Negative control — with `staleDays > mirrorStalenessMaxDays` removed from `mirrorStatus()`, the new test fails (1 of 26); restored, 26/26. E2E 5/5.
|
|
27
|
+
|
|
28
|
+
## Known Limits
|
|
29
|
+
|
|
30
|
+
The shipped baseline IS now stale by the default threshold, so a fresh install correctly reports `stale: true`. That is the feature working and it is deliberately NOT papered over here — refreshing `capturedAt` to make a test green would fabricate a capture that never happened. Whether to ship a newer capture on a cadence is a release decision, named rather than taken.
|
|
31
|
+
|
|
32
|
+
This fixes the one assertion found. No sweep was run for other tests whose verdict depends on wall-clock aging of a committed artifact, and none is claimed.
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
# A test that turned red at a specific minute, on every branch, with nobody touching anything — Plain-English Overview
|
|
2
|
+
|
|
3
|
+
## The problem in one breath
|
|
4
|
+
|
|
5
|
+
One end-to-end test checked that a reference file shipped inside instar was "not stale". That file was captured on 24 July, and the rule is that it goes stale after thirty days. So at **01:20 UTC today** — thirty-one days later — the test started failing everywhere at once. No commit caused it. The clock did.
|
|
6
|
+
|
|
7
|
+
## Why that is worse than an ordinary failure
|
|
8
|
+
|
|
9
|
+
Nothing in the code changed, so nothing in the code looks guilty. Every branch went red simultaneously, including the main one, which makes it read like an infrastructure outage rather than a test making a claim it had no business making.
|
|
10
|
+
|
|
11
|
+
And it blocked everything: nothing could merge, because merges wait on a green build.
|
|
12
|
+
|
|
13
|
+
## What the test was actually entitled to check
|
|
14
|
+
|
|
15
|
+
That the feature is **wired up** — that the reference file is found when the server really boots, that it carries a capture date, and that the "is it stale?" answer it reports agrees with the age it worked out.
|
|
16
|
+
|
|
17
|
+
What it was **not** entitled to check is whether that file happens to be under thirty days old on the day the test runs. That is a fact about how often we ship a fresh capture, not about whether the code works.
|
|
18
|
+
|
|
19
|
+
## What changes
|
|
20
|
+
|
|
21
|
+
The end-to-end test now checks the wiring and the internal consistency of the answer. The staleness rule itself moved to a test where the clock is a dial we set: at exactly thirty days it must report *not stale*, and at thirty-one it must report *stale*.
|
|
22
|
+
|
|
23
|
+
Both sides are pinned deliberately. A "fix" that made nothing ever stale would have satisfied a one-sided test while quietly deleting the warning the feature exists to give.
|
|
24
|
+
|
|
25
|
+
## The safeguard
|
|
26
|
+
|
|
27
|
+
Checked against deliberately broken code: with the staleness rule removed, the new test fails. So it is a test, not a decoration.
|
|
28
|
+
|
|
29
|
+
## One thing worth knowing separately
|
|
30
|
+
|
|
31
|
+
The shipped reference capture really is more than thirty days old now. That means a fresh install will correctly report it as stale — which is the feature working, not breaking. Whether to ship a newer capture is a release-cadence decision, and it is deliberately not made here: silently refreshing the date would have hidden the same information this change exists to preserve.
|
|
32
|
+
|
|
33
|
+
## What you actually need to decide
|
|
34
|
+
|
|
35
|
+
Nothing about the test. Separately, and not urgently: whether the shipped reference capture should be refreshed on a cadence so installs do not inherit a stale one.
|
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
# Side-Effects Review — an aliveness test stops asserting a fact about the calendar
|
|
2
|
+
|
|
3
|
+
**Slug:** `mirror-staleness-is-not-an-aliveness-fact`
|
|
4
|
+
**Date:** 2026-08-24
|
|
5
|
+
**Risk floor:** 1 (tests only; no runtime file touched)
|
|
6
|
+
|
|
7
|
+
## Summary of the change
|
|
8
|
+
|
|
9
|
+
An e2e aliveness test asserted `mirror.stale === false` against a baseline shipped inside the package. The baseline's `capturedAt` is 2026-07-24T01:20Z and the staleness threshold defaults to 30 days, so the assertion turned red at 2026-08-24T01:20Z on every branch at once, main included, with no commit involved. The e2e now asserts the wiring (present, `capturedAt` set, `stale` consistent with `staleDays`); the threshold moves to a unit test with an injected clock, pinned on both sides.
|
|
10
|
+
|
|
11
|
+
## Decision-point inventory
|
|
12
|
+
|
|
13
|
+
None. No runtime decision changes; `mirrorStatus()` is untouched.
|
|
14
|
+
|
|
15
|
+
## 1. Over-block
|
|
16
|
+
|
|
17
|
+
None. The e2e can no longer fail for a reason unrelated to the code under test — which is the point, and is a REDUCTION in false red, not in coverage: the staleness rule is now checked more strictly than before (two points, controlled clock) rather than incidentally.
|
|
18
|
+
|
|
19
|
+
## 2. Under-block
|
|
20
|
+
|
|
21
|
+
Named honestly: the e2e no longer notices if the SHIPPED baseline ages out. That was never something it could report usefully — it could only say "red today, green yesterday, same code" — but the information is real and now has no automated home. It is recorded under Known Limits in the release fragment rather than silently dropped.
|
|
22
|
+
|
|
23
|
+
## 3. Level-of-abstraction fit
|
|
24
|
+
|
|
25
|
+
This is the whole finding. An aliveness test answers "is the feature wired on the production boot path?". Whether a shipped artifact is under thirty days old is a fact about release cadence and belongs where the clock is an input. Putting it in the e2e put a calendar dependency in a layer that cannot control the calendar.
|
|
26
|
+
|
|
27
|
+
## 4. Signal vs authority compliance
|
|
28
|
+
|
|
29
|
+
Not applicable — tests only, no runtime authority.
|
|
30
|
+
|
|
31
|
+
## 4b. Judgment-point check
|
|
32
|
+
|
|
33
|
+
None.
|
|
34
|
+
|
|
35
|
+
## 5. Interactions
|
|
36
|
+
|
|
37
|
+
- **`safe-merge`** refuses on any red check, so this single assertion blocked EVERY merge from 01:20Z. Two open PRs (#1967, and anything opened later) were stuck behind it. That is why the fix is worth doing now rather than filing.
|
|
38
|
+
- **`mirrorStatus()`** is unchanged, so the `precondition-failed / stale-mirror` verdict path and the unit tests around it keep their existing behaviour.
|
|
39
|
+
|
|
40
|
+
## 6. External surfaces
|
|
41
|
+
|
|
42
|
+
None.
|
|
43
|
+
|
|
44
|
+
## 6b. Operator-surface quality
|
|
45
|
+
|
|
46
|
+
Improves it indirectly: the operator stops seeing a repo-wide red that no commit explains.
|
|
47
|
+
|
|
48
|
+
## 7. Multi-machine posture
|
|
49
|
+
|
|
50
|
+
`unified` — tests only, no per-machine state.
|
|
51
|
+
|
|
52
|
+
## 8. Rollback cost
|
|
53
|
+
|
|
54
|
+
Revert two test files. Reverting restores a build that goes red on a timer, so it should not be reverted quietly.
|
|
55
|
+
|
|
56
|
+
## Conclusion
|
|
57
|
+
|
|
58
|
+
Ship.
|
|
59
|
+
|
|
60
|
+
## Phase-5 second pass
|
|
61
|
+
|
|
62
|
+
**Not required, and not run** — no block/allow decision, no session lifecycle, no gate/sentinel/guard/watchdog, no runtime file touched. Stated explicitly so the section below is not mistaken for an independent reviewer's concurrence.
|
|
63
|
+
|
|
64
|
+
## The finding that outlives the fix
|
|
65
|
+
|
|
66
|
+
This is the second time today the same shape has appeared, in two unrelated subsystems: a correctness claim resting on wall-clock timing. This morning it was a thread id whose uniqueness came only from the millisecond (fixed in #1971). Tonight it is a test whose verdict came only from the date. Both fail without a commit, both look like flake, and both get *more* likely with time or speed rather than less.
|
|
67
|
+
|
|
68
|
+
The tempting cheap fix here was to bump `capturedAt` in the shipped baseline. That would have made the suite green in one line and fabricated a capture that never happened — turning a true signal ("the shipped baseline is old") into a false one. Worth naming because it was the obvious move and it was wrong.
|
|
69
|
+
|
|
70
|
+
## Evidence pointers
|
|
71
|
+
|
|
72
|
+
- `origin/main` at `9f83c19ca`, e2e run locally: 1 failed / 4 passed, `expected { present: true, …(3) } to match object { present: true, stale: false }`. Main was red on the clock, not on a change.
|
|
73
|
+
- `src/data/benchmarkPredictions.json` → `capturedAt: 2026-07-24T01:20:00.000Z`; age 31 days; `mirrorStalenessMaxDays` default 30 (`BenchmarkDivergenceAnalyzer.ts:110`).
|
|
74
|
+
- Negative control: with the threshold comparison removed from `mirrorStatus()`, the new unit test fails (1/26). Restored: 26/26. E2E 5/5.
|
|
75
|
+
|
|
76
|
+
## Class-Closure Declaration (display-only mirror)
|
|
77
|
+
|
|
78
|
+
The class is "a test whose verdict depends on wall-clock aging of a committed artifact." Closed for this one assertion. NOT closed generally — no sweep was run for other date-sensitive assertions, and the sibling class named above (correctness resting on wall-clock timing, in runtime code as well as tests) is not swept for either. Named, not claimed.
|