15 / 15 · Acceptance & Fixtures
Build against measurable outcomes
Use deterministic records, numerical budgets and an evidence ledger to decide when the new build is ready.
Targets and fixtures are specifications, not results.
No new application has been regenerated from this package yet. The example report is deliberately marked illustrativeOnly and not-run. HTML and fixture validation proves the package is readable and internally consistent; it does not prove app behavior, Google integration or deployment.
1 · Fixed measurement baseline
| Parameter | Rebuild baseline | How to record |
|---|---|---|
| Machine | At least 4 logical CPU cores and 8 GiB RAM; dedicated app process. | Record CPU, OS, RAM, power mode, Bun and BrowserOS Neo/Chromium versions. If different, mark the comparison non-equivalent. |
| Viewports | Desktop 1280 × 800; mobile layout 390 × 844 CSS pixels. | Test both; keyboard focus and 44px touch targets remain functional gates. |
| Network | 20 Mbps download, 100ms round-trip latency for controlled tests. | Use a controlled proxy or test provider for API timing. A fake delay does not prove real Google latency. Record upload rate separately if measuring upload duration. |
| Data | 1000 notes, 10 non-root Notes folders; each body contains 10 KiB ASCII text. | The title/JSON envelope are additional bytes. Use generated fixtures so every run has the same IDs/content. |
| Source sizes | 1 GiB valid synthetic silent WAV; 10 GiB technical sparse binary. | The binary is only for technical range/size tests, not playable media. Sparse files use logical sizes; uploading still transfers logical bytes. |
| Timing sample | 5 warmups, then at least 30 measured note openings. | Sort elapsed values; p95 is element ceil(0.95 × n) − 1 (zero-based). Report samples, p95 and maximum. |
| Cold versus warm | Cache-first test uses an existing account cache; cold first-load is separate. | Do not claim first-visit offline support. Do not mix uncached results into the warm-cache p95. |
acceptance-targets.json owns the numerical baseline. These are chosen rebuild targets, not historical performance claims. Changing a budget needs an explicit decision recorded with the run; do not relax it after seeing a failure without documenting why.
2 · Budgets and boundary tests
| Check | Pass criterion | Measurement boundary |
|---|---|---|
| Warm note opening | p95 ≤250ms | User activation of a cached note → correct editable document rendered. Delay remote bodies by 3000ms; the note must open before that response. |
| Typing response | p95 input-to-next-render-frame ≤50ms | 1000 input events at 10 events/second in a 10KiB note body. Use browser timing marks and the next animation-frame callback as a rendering-readiness proxy, not a physical display-paint measurement; count serializer and network calls separately. No complete document serialization/network request per keystroke. |
| Incremental refresh | Unchanged: 0 note body reads; one changed note: at most 1 body read | Clean local queue, valid revisions and no conflict/migration/read error. Metadata listing and revision-index bytes are not note body downloads; instrument both separately. |
| Bounded requests | ≤40 note bodies per pull response; ≤16 concurrent Drive reads; ≤8 concurrent Drive writes | Track maximum in-flight provider operations with a fake, then separately inspect a real integration trace. Folder ordering still applies. |
| Source insertion | 0 upload calls; 0 complete-source reads | Only metadata/reference creation during picker selection. Deliberately starting preview/playback may issue bounded range requests; count those separately. |
| Large-source streaming | Peak RSS increase ≤128MiB over baseline | Dedicated app process, 20 sequential 1MiB reads from one sparse source. Record RSS baseline/peak and OS page-cache conditions. This budget does not claim a full 1GiB transfer completes in a fixed time. |
| Request limits | Metadata mutations 64KiB; note sync/search 8MiB; raw chunk 8MiB; complete upload 10GiB | Reject non-identity Content-Encoding with 415; limits apply to streamed serialized UTF-8 JSON/binary body bytes before parsing, including JSON envelopes and escaping; upload size applies to declared and received total. Validate one byte below, exact boundary and one byte above. Canvas retains its separate 512KiB cap. |
| Over-limit behavior | Clear 413 and retained local content/queue | No giant allocation, silent truncation or success acknowledgement. For large note batches split jobs; a single oversized note stays visible/exportable. See API Contracts for envelopes. |
| Data durability | 0 lost confirmed local edits in the specified injected-failure cases | This is a test assertion for the scenario set, not an absolute guarantee against browser/device destruction. |
To observe RSS on Linux, sample /proc/<app-pid>/status (VmRSS) during the controlled stream run. On macOS record ps -o rss= -p <app-pid> values in KiB. Observe the app, not the test runner. Do not compare an absolute process RSS against a delta budget.
3 · Portable fixture files
| File | Contents | Use |
|---|---|---|
| records.json | Two synthetic Google identities, same logical note ID with different contents, separate folders, base/pending/token/tombstone and technical Drive metadata. | Seed isolated test namespaces only; these are not runtime login credentials. |
| document.schema.json | JSON Schema 2020-12 for normalized DocumentRecord plus structural node and technical metadata definitions. | Validate boundaries in the generated app. Node-specific names/attrs/defaults additionally follow chapter 13; a structurally valid unknown node is not automatically supported. |
| api-examples.json | Synthetic requests and outcomes from 11 API Contracts. | Drive fake contract fixtures; never treat them as results from a real provider. |
| markdown-fixtures.json | Schema-valid rich document plus Markdown import/export cases and expected behavior. | Use chapter 13 to separate current codec observations from required rebuild behavior. JSON failures additionally follow api-error.schema.json. |
| acceptance-targets.json; acceptance-cases.json | Baseline, budgets, limits and A01–A12 outcomes. | Machine-readable acceptance inputs; keep prose consistent. A08 must seed the separate live deletionStart record before applying deletion; deleted[] is the expected post-action state. |
| evidence-example.json | Illustrative evidence ledger with null results and not-run status. | Copy and fill with actual evidence. Never replace null with invented measurements. |
| generate.mjs | Dependency-free Bun/Node fixture generator. | Creates a new directory; refuses overwriting. No network calls. Large sparse files are opt-in. |
| verify.mjs | Dependency-free structural and relationship checks. | Checks fixture syntax, field presence, account IDs, folder graph, queue/base and metadata allowlist; not a full JSON Schema validator or app test. |
bun prompt/fixtures/verify.mjs
# Create deterministic note data in a NEW directory:
bun prompt/fixtures/generate.mjs --out ./test-data/generated
bun prompt/fixtures/verify.mjs --generated ./test-data/generated
# Optional large-source fixtures; use another NEW directory:
bun prompt/fixtures/generate.mjs --out ./test-data/generated-large --large
bun prompt/fixtures/verify.mjs --generated ./test-data/generated-largeKeep generated data, credentials and evidence containing account information outside Git. The fixture generator creates local files only; it does not sign in, seed a production account or upload to Drive. Import fixtures through an isolated test harness that enforces the same record schemas as the app.
4 · Required scenario set
| Case / requirements | Controlled event | Expected outcome |
|---|---|---|
| A01 · Core source reuse FR-09, FR-11, FR-17 · V16 | Insert existing 1GiB Drive source, annotate, sync, reopen. | Same file ID; zero upload calls and zero full-source reads during insertion; annotations retained. |
| A02 · Cache-first opening FR-02, FR-13, NFR-04 · V02/V08 | 1000 notes, warm browser cache; remote content delayed 3000ms; open 30 notes after 5 warmups. | p95 <=250ms; complete local editor opens before delayed Drive completes. |
| A03 · Typing responsiveness FR-03, NFR-04 · V03 | 1000 input events at 10 per second in a 10KiB body; measure event to next rendered frame. | p95 <=50ms; no full serialization or HTTP request for every keystroke. |
| A04 · Bounded pull FR-13, NFR-05 · V08 | Pull unchanged 1000-note revisions, then change exactly one remote note. | 0 body reads when unchanged, <=1 changed body read; <=40 document bodies per response; read<=16, write<=8. |
| A05 · Large range streaming FR-09, NFR-05 · V11 | Request 0-99, open-ended/suffix, then 20 sequential 1MiB ranges from sparse source. | Correct 206 bytes and headers; invalid ranges return 416. RSS growth is <=128MiB; do not buffer the whole file. |
| A06 · Offline queue retention FR-12, FR-15, NFR-03 · V07/V10 | Block the network, make 30 edits, reload, inject 429/503 and a lost response, then reconnect. | All local text/bases/jobs survive; one canonical Drive note per ID; exact confirmed jobs only removed. |
| A07 · Stale acknowledgement FR-12, FR-14, NFR-03 · V09 | Dispatch fixture-token-1, then store fixture-token-2 before first acknowledgement. | fixture-token-2 stays pending; newer editor text is not overwritten. |
| A08 · Permanent deletion race FR-07 · V06 | Seed accounts[0].deletionStart.note and its Drive mapping as live; delay detail/list/push responses, delete doc-deleted, deliver older results and reload. records.deleted[] is expected post-action state. | No editor/list/cache resurrection; remote deletion status remains honest. |
| A09 · Account separation FR-01, FR-02, NFR-02 · V01/V10 | Switch between two fixture users with same doc-example ID; include offline reload and another account ticket. | Only active account content; cross-account access denied, no former-account private response cache. |
| A10 · Failure decisions FR-11, FR-14, FR-17, NFR-03 · V07/V09/V16 | Inject invalid_grant, a storage-quota 403, an inaccessible-source 404, malformed Markdown and an IndexedDB quota error. | Match chapter 12: no note/source destruction, blank overwrite or false saved status. |
| A11 · Request and file limits FR-10, NFR-05, NFR-09 · V11 | Test limit minus 1 byte, the exact limit and limit plus 1 byte for metadata, sync/search, chunks and declared upload size. | Accept valid exact-boundary payloads; above the boundary return HTTP 413 with maxBytes. Preserve local jobs; no truncation or giant allocation. |
| A12 · Recovery and delivery FR-16, NFR-01, NFR-08, NFR-10 · V10/V15 | Restore synthetic metadata/notes into isolated root; reconcile queue before resume; follow clean install from another folder. | No readable editor notes in server backup; no automatic replay of stale deletes; exact install/start steps and actual evidence recorded. |
Run all A01–A12 for the web core where configured. If an external integration cannot be tested, keep its live layer open even when the fake passes. Optional FR-18–21 each need their V12/V13 checks in addition to the relevant core cases.
5 · Filled example of evidence classification
The following row shows how to write a report, not an actual app test result. The failure is hypothetical. It deliberately demonstrates that a measured failure cannot be reported as passing.
| Example row | Illustrative observation | Correct classification |
|---|---|---|
| A02 · fake cache timing | Example only: hypothetical p95 310ms with a 250ms target. No such benchmark was performed here. | Illustrative FAIL; record the real generated-build measurements separately before assigning any actual status. |
| A01 · source reuse | A fake test would count uploads/full reads and assert both are zero. | Fake pass alone leaves real OAuth/Drive verification not-run. |
| Production release | No deployment requested as part of independent construction. | Not performed; a local build does not imply a live release. |
Scope: web core (FR-01–17 and applicable NFRs)
Generated build commit: <actual SHA>
Environment/date: <actual baseline and date>
Requirement | Story | Scenario/Case | Actual result | Evidence | Status | Limitation
FR-17 | US-11 | V16/A01 | <actual only> | <path> | open | live Drive not yet verified
NFR-04 | US-05 | V08/A02 | <raw samples> | <path> | open | baseline not recorded
Layers: fixture validation / schema validation / unit+fake integration /
BrowserOS Neo desktop / BrowserOS Neo 390px / real Google OAuth+Drive / deployment
Each layer: command or steps, actual result, environment, artifact path, timestamp.
A blocked external dependency is recorded as open, not silently skipped or passed.Use build-status.md as the new project’s durable ledger. The JSON template starts at not-run; the table above is illustrative reporting guidance. Neither is a substitute for actual command output.
6 · Handoff to an empty folder
- Copy the entire
prompt/directory, includingfixtures/andbaseline/. No original source path is needed to read or execute the package’s fixture tools. - Read chapter ownership/precedence in 07 Sources & decisions, then begin P00 using the master prompt. Do not run all phases as one undocumented code dump.
- Use the exact setup baseline in chapter 14; create the new app’s own manifest/lockfile, configuration and synthetic data. Credentials are supplied separately by the owner.
- At P01 verify both account-local namespaces. At P03 use a fake Drive source; at P04 complete V16 with real source insertion, annotation and reopening when authorized test credentials are available.
- Finish the selected scope, execute A01–A12 and each mapped V scenario, and inspect the result in BrowserOS Neo. Record gaps where the package was insufficient rather than guessing silently.
- Deliver source, lockfile, README, schema/tests, evidence ledger and known limitations. Publication remains a separate action.
The human owner will perform the independent build after this documentation task. Do not pre-fill a claim that the empty-folder reconstruction has passed.