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
@@ -19,6 +19,37 @@
- 운영 절차:
[API contract와 server-state recovery](../operations/api-contract-and-server-state-recovery.md)
## Installed binding snapshot과 stream cleanup bound (R-01, R-04, R-05, R-06)
- `installBrowserRpcContractBindings()`가 registry를 **parse → validate →
install** 순서로 처리한다. own data descriptor만 읽어 exact key set으로
null-prototype frozen snapshot을 만들고, 그 snapshot을 검증한 뒤 설치한다.
getter/accessor, extra key, symbol key, malformed descriptor, revoked proxy는
composition-time `TypeError`이며 getter는 호출조차 되지 않는다. runtime과
transport call은 이후 snapshot만 읽으므로 validation 이후 registry mutation이
replay policy·deadline·byte ceiling·transport selection을 바꿀 수 없다.
- server stream 종료는 transport iterator에 lifecycle authority를 위임하지
않는다. commit/admission generation은 즉시 fence하고 listener는 바로 해제하며,
`iterator.return()`은 cleanup **요청**으로서 bound 안에서만 기다린다. 끝나지
않은 cleanup은 관찰만 유지되고(unhandled rejection 없음) application generator는
bound 안에 종료된다. cleanup rejection은 이미 선택된 application failure를
덮지 않는다.
- WebSocket text frame은 allocation 전에 admission한다. UTF-16 code unit 길이가
이미 cap을 넘으면 encoder를 만들지 않고 거절하고, 나머지는 early exit하는
code-point 누적으로 센다. valid surrogate pair는 4 bytes, lone surrogate는
`TextEncoder`와 동일하게 replacement 3 bytes다.
- clock/fence collaborator 예외는 Result 경계를 벗어나지 않는다. clock 실패는
`SERVER_FAILURE/RPC_RUNTIME_DEPENDENCY_FAILED`, capture 실패는
`SCOPE_GENERATION_CHANGED/RPC_SCOPE_GENERATION_UNAVAILABLE`, `isCurrent` 실패는
fail-closed로 canonicalize하며 listener/timer는 단일 exit path에서 정확히 한 번
해제한다.
Browser RPC는 여전히 `AVAILABLE_NOT_COMPOSED`다. 선택된 Connect/gRPC-Web
transport는 enqueue-time `maxBufferedBytes`, raw/decompressed ceiling,
cancel/closed receipt, terminal framing, target browser와 load behavior를
별도로 증명해야 조립할 수 있다 (R-07).
## 1. 먼저 축을 분리한다
네 이름은 같은 종류의 대안이 아니다.