chore: sync the frontend template from 4dc033c to 8157ad4

The product was materialized from the template at `4dc033c` and has stayed
on it through 43 template commits, so it was missing all three rounds of
adapter remediation — including files it never had, such as the shared
`abortable-operation` primitive and the `exact-snapshot` decoder that
later fixes are written against. Taking only the newest round was not
possible for that reason: the delta is coherent only as a whole.

The product had not touched `src/adapters` at all since materialization,
so the 140-file delta applied with a three-way merge and no conflicts.
`package.json` was the single overlap and merged cleanly: the product owns
`name`, the template contributed `check:adapter-inventory`,
`check:remediation-ledger` and the image-resolve-signal type fixture.
All 24 product-owned files — README, index.html, CI workflow, i18n
catalog, home page, generated schemas, evidence scripts, component and
visual snapshots — are byte-identical to `main`.

`template.lock.json` now pins the synced revision and tree.

Verified in this repository, not inherited from the template: six type
projects, lint, nine gates (adapter inventory, remediation ledger,
registries, diagnostics, realtime boundaries, architecture, browser
file/storage boundaries, optional recipes, documentation), the production
build, and 2,054 of 2,073 tests. The 19 failures are all in
`tests/unit/ci-artifact-contract.test.ts` and are the same pre-existing
sandbox RLIMIT, EMFILE, umask and `/tmp` permission behaviour the template
records; four suites that failed once under parallel load pass in
isolation.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
DongHyeonka
2026-08-15 12:04:58 +09:00
co-authored by Claude Opus 5
parent 002ba3624e
commit 4bff9ca151
142 changed files with 23010 additions and 1544 deletions
+37 -10
View File
@@ -183,7 +183,7 @@ describe("IndexedDB resumable upload checkpoint", () => {
).toMatchObject({ ok: true });
expect(await runtime.admin.deletePartition()).toEqual({
ok: true,
value: { state: "DELETED" },
value: { state: "DELETED", effect: "APPLIED" },
});
expect(await runtime.store.read("upload_key_01")).toMatchObject({
ok: false,
@@ -191,21 +191,48 @@ describe("IndexedDB resumable upload checkpoint", () => {
});
});
it("bounds a partition deletion blocked by another browser context", async () => {
it("returns PENDING UNKNOWN when deleteDatabase is still blocked", async () => {
const memory = new MemoryIndexedDbFactory();
const factory = deletingFactory(memory, "BLOCKED");
const runtime = createIndexedDbResumableUploadCheckpointRuntime({
scope,
factory: deletingFactory(memory, "BLOCKED"),
factory,
blockedTimeoutMs: 1,
});
// BT-UP-03. The native request is still live, so the deadline is not
// evidence that nothing happened.
expect(await runtime.admin.deletePartition()).toEqual({
ok: true,
value: {
state: "PENDING",
effect: "UNKNOWN",
reason: "BLOCKED_DEADLINE",
},
});
});
it("keeps the checkpoint store closed until a pending delete is resolved externally", async () => {
const memory = new MemoryIndexedDbFactory();
const factory = deletingFactory(memory, "BLOCKED");
const runtime = createIndexedDbResumableUploadCheckpointRuntime({
scope,
factory,
blockedTimeoutMs: 1,
});
expect(await runtime.admin.deletePartition()).toMatchObject({
ok: false,
error: {
code: "BLOCKED",
retryable: true,
recovery: "RELOAD_OTHER_CONTEXTS",
},
ok: true,
value: { state: "PENDING" },
});
// A second runtime over the same realm and database would race an unknown
// native effect.
expect(() =>
createIndexedDbResumableUploadCheckpointRuntime({
scope,
factory,
blockedTimeoutMs: 1,
}),
).toThrow(TypeError);
});
it("never reports a false abort after irreversible deleteDatabase dispatch", async () => {
@@ -219,7 +246,7 @@ describe("IndexedDB resumable upload checkpoint", () => {
controller.abort();
expect(await deletion).toEqual({
ok: true,
value: { state: "DELETED" },
value: { state: "DELETED", effect: "APPLIED" },
});
const preAborted = new AbortController();