test: dire exactement ce que le controle e2e mesure, qui est moins qu-il n-y parait
Le controle « une cle qui tombe pour un AUTRE document laisse le scope refuse » mesure l'ISSUE, pas le ciblage : il ne separe pas « aucune reouverture n'a ete tentee » de « une a ete tentee et refusee a nouveau », les deux finissant au meme endroit. Le ciblage se mesure au compte de notifications, dans la suite unitaire. Nommer ce qu'un controle vert prouve est toute la lecon du tour qui a livre cette barriere sans aucune couverture de scope nomme.
This commit is contained in:
@@ -133,7 +133,7 @@ Fix: the keyring signal now RE-OPENS a scope the barrier refused, gated on `name
|
|||||||
|
|
||||||
**Finding 2 - the INERT claim was false.** Reproduced by reading and pinned as (u): `ensureRepoOpen` runs whatever the registry is enforcing, so the inert case gained a real `doc_subscribe` and a barrier wait. The open is right and stays; what was wrong was calling it "unchanged". The measured COST was real though: the barrier was SERIAL, so N documents that never push a `State` cost N bounded fallbacks - 8s each in production. Now parallel, so the wait is the slowest rather than the sum, with the refusals still read in scope order afterwards. Pinned by (t), which fails on the serial form.
|
**Finding 2 - the INERT claim was false.** Reproduced by reading and pinned as (u): `ensureRepoOpen` runs whatever the registry is enforcing, so the inert case gained a real `doc_subscribe` and a barrier wait. The open is right and stays; what was wrong was calling it "unchanged". The measured COST was real though: the barrier was SERIAL, so N documents that never push a `State` cost N bounded fallbacks - 8s each in production. Now parallel, so the wait is the slowest rather than the sum, with the refusals still read in scope order afterwards. Pinned by (t), which fails on the serial form.
|
||||||
|
|
||||||
**And the thing that let both through: the e2e never walked this path.** Confirmed - both `useShapeQuery` journeys read `{graphs: "did:ng:i"}`, so `43 passed / 43` was never evidence for the barrier, and reporting it as such was the real failure of round 1. Four live checks added over a NAMED scope: the owner reads her own document (the barrier does not break a live named read); a holder of nothing is `isError` with the refusal's own message and `dataLen: 0`, never an empty success; a PUBLIC document opens for that same holder from a bare reference, through the barrier's own fetch; and a cap landing for ANOTHER document leaves the refused scope refused rather than churning.
|
**And the thing that let both through: the e2e never walked this path.** Confirmed - both `useShapeQuery` journeys read `{graphs: "did:ng:i"}`, so `43 passed / 43` was never evidence for the barrier, and reporting it as such was the real failure of round 1. Four live checks added over a NAMED scope: the owner reads her own document (the barrier does not break a live named read); a holder of nothing is `isError` with the refusal's own message and `dataLen: 0`, never an empty success; a PUBLIC document opens for that same holder from a bare reference, through the barrier's own fetch; and a cap landing for ANOTHER document leaves the refused scope refused. That fourth one measures the OUTCOME only - it does not separate "no re-open was attempted" from "one was attempted and refused again"; the targeting itself is measured by the notification count in `use-shape-query.test.ts` (s). Saying which of the two a green check proves is the whole lesson of the round that shipped this barrier with no named-scope coverage.
|
||||||
|
|
||||||
**What the e2e still does NOT prove, stated plainly.** The POSITIVE recovery - the cap for the refused document itself arriving - is proven at unit level only (test r, non-vacuous). Driving it live needs a second actor delivering through `inbox.share`, and on one page that means switching the current identity while the observable is subscribed, which would re-open the refused scope under the OTHER identity. That is a pre-existing property of this observable (`publish` has always read the keyring of whoever is connected), it cannot arise in an application (one identity per page load, no call takes an identifier), and the repo has already ruled that such montages belong in the applicative suite - `capsShareCap` was moved there for exactly this reason. Left as a named follow-up rather than encoded here as if it were the library's behaviour.
|
**What the e2e still does NOT prove, stated plainly.** The POSITIVE recovery - the cap for the refused document itself arriving - is proven at unit level only (test r, non-vacuous). Driving it live needs a second actor delivering through `inbox.share`, and on one page that means switching the current identity while the observable is subscribed, which would re-open the refused scope under the OTHER identity. That is a pre-existing property of this observable (`publish` has always read the keyring of whoever is connected), it cannot arise in an application (one identity per page load, no call takes an identifier), and the repo has already ruled that such montages belong in the applicative suite - `capsShareCap` was moved there for exactly this reason. Left as a named follow-up rather than encoded here as if it were the library's behaviour.
|
||||||
|
|
||||||
@@ -143,7 +143,7 @@ Fix: the keyring signal now RE-OPENS a scope the barrier refused, gated on `name
|
|||||||
- `bunx tsc --noEmit -p packages/polyfill/tsconfig.json` -> exit 0
|
- `bunx tsc --noEmit -p packages/polyfill/tsconfig.json` -> exit 0
|
||||||
- `bunx tsc --noEmit -p packages/polyfill/e2e/tsconfig.json` -> exit 0
|
- `bunx tsc --noEmit -p packages/polyfill/e2e/tsconfig.json` -> exit 0
|
||||||
- `python3 ~/.claude/skills/concept/lint.py` -> 0 ERROR (warnings pre-existing; the new leaf carries none)
|
- `python3 ~/.claude/skills/concept/lint.py` -> 0 ERROR (warnings pre-existing; the new leaf carries none)
|
||||||
- polyfill e2e, run at HEAD: `Polyfill e2e summary: 47 passed, 0 failed, 47 total - batch 3.5 min, slowest cold sync 30s`. 43 was the count before this task; the four added are the named-scope checks described above. NOTE: the broker login is flaky - two of eight runs died with `[e2e broker login] gave up after 45.0s - the wallet-list screen never changed`, at a different step each time, before any library code runs.
|
- polyfill e2e, run at HEAD: `Polyfill e2e summary: 47 passed, 0 failed, 47 total - batch 3.4 min, slowest cold sync 29s`. 43 was the count before this task; the four added are the named-scope checks described above. NOTE: the broker login is flaky and independent of this work - three of ten runs in this session died with `[e2e broker login] gave up after 45.0s - the wallet-list screen never changed`, at a different step each time, on the login UI before any library code runs. Every such run was re-run to a clean result.
|
||||||
|
|
||||||
### The contract
|
### The contract
|
||||||
|
|
||||||
|
|||||||
@@ -519,14 +519,22 @@ async function main(): Promise<void> {
|
|||||||
|
|
||||||
// That fetch FILED a cap, which fires `CapRegistry.onChange` - the channel a
|
// That fetch FILED a cap, which fires `CapRegistry.onChange` - the channel a
|
||||||
// refused scope is re-opened on since `1.0.0-dev.9`, because the barrier aborts
|
// refused scope is re-opened on since `1.0.0-dev.9`, because the barrier aborts
|
||||||
// before any query exists and `publish` has nothing to re-filter. It has to be
|
// before any query exists and `publish` has nothing to re-filter. This cap says
|
||||||
// TARGETED: this cap says nothing about the protected document, so the refusal
|
// nothing about the protected document, so the refusal must stand.
|
||||||
// stands rather than buying a round-trip per cap for the rest of the session.
|
//
|
||||||
// The positive direction - the cap for the refused document itself arriving -
|
// What this measures, exactly, and it is less than it might look: the OUTCOME is
|
||||||
// needs a second actor delivering it, and lives in the applicative suite.
|
// unchanged. It does not separate "no re-open was attempted" from "one was
|
||||||
|
// attempted and refused again" - both end here - so the targeting itself is
|
||||||
|
// measured in the unit suite, by the notification count (`use-shape-query.test.ts`
|
||||||
|
// (s)). Saying which of the two a green check proves is the whole lesson of the
|
||||||
|
// round that shipped this barrier with no named-scope coverage at all.
|
||||||
|
//
|
||||||
|
// The positive direction - the cap for the refused document ITSELF arriving, and
|
||||||
|
// the view converging - needs a second actor delivering it, and belongs in the
|
||||||
|
// applicative suite; `use-shape-query.test.ts` (r) is its unit form.
|
||||||
const afterOtherCap = await sdkGet<any>(frame, "useShapeQuerySnapshot", refused);
|
const afterOtherCap = await sdkGet<any>(frame, "useShapeQuerySnapshot", refused);
|
||||||
check(
|
check(
|
||||||
"a cap landing for ANOTHER document leaves a refused scope refused, not churning",
|
"a cap landing for ANOTHER document leaves a refused scope refused",
|
||||||
afterOtherCap.isError && !afterOtherCap.isSuccess && afterOtherCap.dataLen === 0,
|
afterOtherCap.isError && !afterOtherCap.isSuccess && afterOtherCap.dataLen === 0,
|
||||||
`snap=${JSON.stringify(afterOtherCap)}`,
|
`snap=${JSON.stringify(afterOtherCap)}`,
|
||||||
);
|
);
|
||||||
|
|||||||
Reference in New Issue
Block a user