kayg/calternal
Watch
1
0
Fork
You've already forked calternal
 0
Code Issues 190 Pull requests 61 Projects Releases Packages Wiki Activity Actions 26

Plan amendment: quota under real workloads (#764) #769

Open
kayg wants to merge 33 commits from docs/quota-plan-2 into dev
pull from: docs/quota-plan-2
merge into: kayg:dev
Conversation 3 Commits 33 Files changed 68 +8239 -554
kayg commented 2026-10-30 04:14:22 +00:00
Owner
Copy link

App saves currently trigger repeated whole-Home recounts: the supplied perf VM results show 26.6–26.8% typing CPU and a roughly 15 s cold recount at 100k files. Amend the quota plan before implementation with 22 workload cases, exact own-write deltas and checked echo receipts, explicit same-path outside-writer invalidation, a restart recommendation, perf gates and an updated failure table.

Recommend optimizing the complete cold recount and requiring successful 100k admission within 2 s. Persisted totals remain hints without proven durable change detection; far-below quota does not bound arbitrary offline changes. The amendment also identifies legacy single-root SQLite/WAL churn and the #761 two-tree counting boundary as requirements to resolve before claiming a typing pass.

Only docs/plans/0754-quota.md changes. Based on perf/quota-simple at a506b739f0. No product code or deployment.

Validation:

  • Amendment: 1,828 words, three A4 pages at 10.5 pt body / 9.5 pt tables and 14 mm margins.
  • Forgejo GFM render: HTTP 200, all 22 workload rows and both amendment tables present.
  • git diff --check passed; scope check confirms only the quota plan changes.
  • No product builds, tests or perf runs performed. Implementation correctness and VM performance gates are specified requirements, not claimed results.

Refs #764, #767 and #761.

App saves currently trigger repeated whole-Home recounts: the supplied perf VM results show 26.6–26.8% typing CPU and a roughly 15 s cold recount at 100k files. Amend the quota plan before implementation with 22 workload cases, exact own-write deltas and checked echo receipts, explicit same-path outside-writer invalidation, a restart recommendation, perf gates and an updated failure table. Recommend optimizing the complete cold recount and requiring successful 100k admission within 2 s. Persisted totals remain hints without proven durable change detection; far-below quota does not bound arbitrary offline changes. The amendment also identifies legacy single-root SQLite/WAL churn and the #761 two-tree counting boundary as requirements to resolve before claiming a typing pass. Only `docs/plans/0754-quota.md` changes. Based on `perf/quota-simple` at a506b739f001c85336ae8a234aadbfcd2d78e3f2. No product code or deployment. Validation: - Amendment: 1,828 words, three A4 pages at 10.5 pt body / 9.5 pt tables and 14 mm margins. - Forgejo GFM render: HTTP 200, all 22 workload rows and both amendment tables present. - `git diff --check` passed; scope check confirms only the quota plan changes. - No product builds, tests or perf runs performed. Implementation correctness and VM performance gates are specified requirements, not claimed results. Refs #764, #767 and #761.
docs: amend quota plan for real workloads
Some checks failed
CI / server (pull_request) Successful in 1m17s
Details
CI / rust (pull_request) Failing after 8m33s
Details
CI / web (pull_request) Has been cancelled
Details
6c3f7f8a4f
kayg commented 2026-10-30 04:20:05 +00:00
Author
Owner
Copy link

Independent design review — round 1 of at most 3.

Verdict: approve with required edits. The direction is sound: exact deltas for proven app publications, conservative recounts for ambiguity, and a measured cold recount rather than trusting offline totals. Three requirements below need to be explicit before this becomes the implementation contract. This is approval of the design direction, not of a working fast path or its performance.

Reviewed PR #769, docs/quota-plan-2 at 6c3f7f8a4f68b180c79f377b076d07fa93d7e62b, against perf/quota-simple at a506b739f001c85336ae8a234aadbfcd2d78e3f2. Fresh detached worktree: /home/agent/wt/review-769, on 10by32-01-std. Read the entire plan, scanner/watch/event/fence code, Auth and HTTP admission, file publication and note-save paths, state-root setup, and Contacts history accounting. Read the seven #754 review reports and the #764 review/follow-up reports, and inspected the reviewer branch test inventory and relevant historical tests, including round-3 mode transitions. No product or test code was changed. No build, runtime test, perf run, merge or deployment was performed for this docs-only review.

Required edits, in priority order

  1. P2 — Define the new-inode coverage handoff, including a size observation after watch installation. At plan lines 163–171, spell out what “verified owned coverage extension” proves before it can avoid R. Pin the exact inode; establish its watch incarnation; then read/validate its chargeable size, type, link count and mount/domain identity through the pinned object under that coverage. Check publication endpoints and drain the ordered fence before certifying the resulting total. A size captured while preparing the file is insufficient. A mismatch must dirty/refuse or enter another explicitly validated transition, never keep the original payload length as verified authority. If staging is to provide an alternative continuity proof, specify that proof.

    Concrete missing interleaving: prepare and close an 8-byte named staging file; an outside writer extends that same inode to 1,009 bytes before its inode watch is installed; install the watch and publish it. No inode MODIFY predating installation will be replayed. Identity and rename cookie can still match. A receipt using the prepared length would certify 8 bytes and could permit an upload against a 100-byte limit. Watching “before exposure” alone does not close this interval. Today watch_identity verifies identity/type before inotify_add_watch, and new registration dirties the Home (watch/linux.rs:160–213); that invalidation forces another observation. The amendment deliberately introduces an exception, so its replacement proof must be explicit. This is a design gap, not a reproduced bug in an implementation that does not yet exist.

    Add this exact pre-watch growth/truncate/replace adversary to the required deterministic tests, alongside the already requested after-publication tests. A correct implementation can retain D(1): this needs a local covered observation, not a Home walk.

  2. P2 — Specify receipt concurrency and make its tests explicit. At lines 153–181 and 208–213, require the same per-person publication/accounting serialization for note saves, uploads, companion writes, rename/delete and provider transitions that participate in the verified total. Define the point at which a receipt becomes eligible to consume events, when its delta becomes visible to admission, and when it is retired. Either keep serialization through the closing fence/accounting commit or specify how unresolved receipts prevent stale admission. Concurrent staging is fine. The event reader must not need a publication lock held by a writer waiting for its fence.

    Add named cases for two prepared app writes to the same destination, two different destinations in one Home, a save racing a real Auth upload, and a recount/watch-prune racing publication. Delay delivery across receipt registration, delta commit and retirement; interleave directory and inode notifications and back-to-back replacement cookies. Assert exactly-once accounting and real allowed/refused Auth outcomes. A receipt must never consume another operation's event or let a failed/stale operation clear newer dirtiness. Preserve the one-reader kernel ordering; test userspace scheduling permutations rather than treating arbitrary kernel event reordering as normal.

    The plan already mentions accounting sequence, watch generations and races at every boundary. These edits turn that general requirement into an auditable contract for the specifically requested two-writes-in-flight case. Today's Auth guard covers uploads (auth/src/quota.rs:80–127); the note placement path independently invokes Prepared::place, so a common lock cannot be assumed to exist already.

  3. P2 — Make both state layouts explicit merge gates, and state how the default layout gets the typing fix. Lines 143–146 correctly acknowledge the problem, but leave a central supported configuration unresolved. Require W01/W02/W07/W09 to run separately on (i) an existing default installation with no --state, including preexisting DB/WAL/SHM files, and (ii) a separate-state installation. Before accepting the product change, choose and document either a safe state migration with its crash/recovery and charge-preservation rules, or a proven accounting protocol for those in-place DB writes. If the choice is deferred, explicitly keep the product merge blocked for the default layout; a split-state-only typing pass cannot satisfy the fix.

    Tie those variants to the existing 60-second typing/zero-own-save-R/≤2% gate and exact-charge oracle, and require a W01–W22 evidence checklist on the final product head before product merge. For capacity/known-failure variants, record the actual exercised limit/failure, bounded refusal and measured recovery where recovery is possible; a skipped/unrun cell is missing evidence. Identify which 1M/100-Home cells document unsupported capacity rather than promise successful ≤2-second admission. This preserves the plan's honest limits without letting '?' or an expected failure hide an unexecuted workload.

Own-write suppression assessment

The amendment is substantially stronger than a pathname/time window. An app operation ID is only an application key; it does not identify the writer of a kernel event. The safe part of this design is that completed staging removes legitimate app content MODIFY events from the suppressible set. The receipt then accounts for a narrowly verified namespace/lifecycle transition. Subject to edits 1–2, the requested cases have conservative outcomes:

Scenario Required interpretation of this plan
Outside truncate/grow or equal-size edit immediately after save The new inode is already watched. Every MODIFY dirties, even if name, size or mtime later returns to its prior value. Truncation alone can overcount; growth after it is the undercount adversary. Both need the test.
Outside rename-over/replace Extra directory move/create/delete events, different inode identity or unmatched cookie revoke the receipt. Never match only the current pathname.
Outside hard link or old open fd Ambiguous link topology takes R; an outside content write on a retained alias dirties every owning Home through inode coverage. Do not suppress globally because one owner has a receipt. An unlinked old fd with no counted alias contributes no current name.
Two app writes in flight Staging may overlap; publication and accounting must obey edit 2. Distinct operation IDs alone do not provide serialization or a commit order.
Delayed/coalesced notifications Admission still fences the one reader. Do not infer event multiplicity from one notification; if a lifecycle sequence cannot be proved, invalidate. Coalescing is not reliably marked with a “coalesced” flag.
Overflow/watch loss/incarnation reuse Revoke affected receipts and coverage; dirty all possibly affected Homes; rebuild and fence. No delta-only recovery or provisional admission.

Keep the earlier containment obligations literally operative: raw names and fd-relative no-follow descent, device/mount-ID exclusion and mountinfo readiness, all-owner alias invalidation, watch-incarnation protection, bounded retries/queues, and no admission from fallback/provisional totals. In particular, preserve the anti-vacuity checks: actual configured inode reuse, actual kernel overflow in its explicit test, exact successful reads, and positive allowed Auth admissions after recovery. The old #764 non-linearizable fallback reproducer must continue to refuse.

Three workload spot checks against a506b739

  • W01, typing: Prepared::new closes a flushed image and Prepared::place exchanges/places it; the successful callback reaches usage::wrote. Usage::changed adds a provisional amount and dirties the Home (usage.rs:528–534), and ordinary native events also dirty it. Therefore repeated full recounts are a credible explanation of the reported CPU result. D(1) is a proposed outcome, correctly conditional on receipt coverage and the state boundary; it is not current behavior.
  • W04, outside 50k import: the walker uses one statx supplying size/type/inode/mount ID per eligible regular name (scan.rs:82–106, 228–244). Thus 60k/150k/1.05M regular-file metadata observations per completed pass are consistent with adding 50k to the three initial fixtures. Directory metadata, unknown d_type entries, watch setup and rejected/repeated passes are additional costs. The amendment correctly distinguishes these from one guaranteed pass or an end-to-end latency measurement. Its one-statx description supersedes the older introductory two-call estimate.
  • W09, app state: omitting --state assigns state = data (calternal/src/args.rs:169); notes use <state>/users/<id>/notes, including history/meta DBs. The Home walker charges regular names without a SQLite exception. WAL/DB changes therefore invalidate the same Home. Split state avoids those filesystem recounts, but provider logical bytes still need their own generation/failure contract. Existing providers return plain u64; that API alone is not the proposed stable provider fence.

No additional top-level workload family is needed beyond the 22 rows. The missing mandatory variants are the pre-watch handoff, concurrent receipts/admission, and explicit legacy/split-state gates above. Keep payload bytes and topology as independent fixture dimensions: a tiny-file 100k tree alone cannot qualify long-note autosave, large-photo, sparse, huge-flat-folder or two-disk behavior. Those variants are already called for in the matrix and restart discussion.

Restart and perf-gate assessment

Recommendation (c) is safe and candid. It keeps complete live coverage, refuses unverifiable offline state, does not claim directory/file mtimes prove continuity, rejects “far below quota” as a bound on external growth, and distinguishes a quick 503 from successful admission. Parallel work is a hypothesis to profile, not a promised fourfold gain. A ~15-second starting point still needs a substantial improvement to reach two seconds; the explicit release block if that fails is necessary. Existing 64 KiB enumeration/d_type skipping is correctly acknowledged. Keep the independent flat-folder benchmark because directory-level parallelism does not distribute one huge folder automatically.

The gate section already requires perf-test VMs, pinned release heads, all 22 rows at all three sizes, cold/warm repetitions, success/refusal counts, resource/call/fallback measurements and five-minute idle tails. It covers the risky rows in principle. With edit 3's layout variants and evidence/merge checklist, it is enforceable as a pre-product-merge requirement. None of the proposed pass predictions has been independently measured in this design review, and none should be reported as a performance pass merely because this amendment merges.

Independent design review — round 1 of at most 3. **Verdict: approve with required edits.** The direction is sound: exact deltas for proven app publications, conservative recounts for ambiguity, and a measured cold recount rather than trusting offline totals. Three requirements below need to be explicit before this becomes the implementation contract. This is approval of the design direction, not of a working fast path or its performance. Reviewed PR #769, `docs/quota-plan-2` at `6c3f7f8a4f68b180c79f377b076d07fa93d7e62b`, against `perf/quota-simple` at `a506b739f001c85336ae8a234aadbfcd2d78e3f2`. Fresh detached worktree: `/home/agent/wt/review-769`, on `10by32-01-std`. Read the entire plan, scanner/watch/event/fence code, Auth and HTTP admission, file publication and note-save paths, state-root setup, and Contacts history accounting. Read the seven #754 review reports and the #764 review/follow-up reports, and inspected the reviewer branch test inventory and relevant historical tests, including round-3 mode transitions. No product or test code was changed. No build, runtime test, perf run, merge or deployment was performed for this docs-only review. **Required edits, in priority order** 1. **P2 — Define the new-inode coverage handoff, including a size observation after watch installation.** At plan lines 163–171, spell out what “verified owned coverage extension” proves before it can avoid R. Pin the exact inode; establish its watch incarnation; then read/validate its chargeable size, type, link count and mount/domain identity through the pinned object under that coverage. Check publication endpoints and drain the ordered fence before certifying the resulting total. A size captured while preparing the file is insufficient. A mismatch must dirty/refuse or enter another explicitly validated transition, never keep the original payload length as verified authority. If staging is to provide an alternative continuity proof, specify that proof. Concrete missing interleaving: prepare and close an 8-byte named staging file; an outside writer extends that same inode to 1,009 bytes before its inode watch is installed; install the watch and publish it. No inode MODIFY predating installation will be replayed. Identity and rename cookie can still match. A receipt using the prepared length would certify 8 bytes and could permit an upload against a 100-byte limit. Watching “before exposure” alone does not close this interval. Today `watch_identity` verifies identity/type before `inotify_add_watch`, and new registration dirties the Home (`watch/linux.rs:160–213`); that invalidation forces another observation. The amendment deliberately introduces an exception, so its replacement proof must be explicit. This is a design gap, not a reproduced bug in an implementation that does not yet exist. Add this exact pre-watch growth/truncate/replace adversary to the required deterministic tests, alongside the already requested after-publication tests. A correct implementation can retain D(1): this needs a local covered observation, not a Home walk. 2. **P2 — Specify receipt concurrency and make its tests explicit.** At lines 153–181 and 208–213, require the same per-person publication/accounting serialization for note saves, uploads, companion writes, rename/delete and provider transitions that participate in the verified total. Define the point at which a receipt becomes eligible to consume events, when its delta becomes visible to admission, and when it is retired. Either keep serialization through the closing fence/accounting commit or specify how unresolved receipts prevent stale admission. Concurrent staging is fine. The event reader must not need a publication lock held by a writer waiting for its fence. Add named cases for two prepared app writes to the same destination, two different destinations in one Home, a save racing a real Auth upload, and a recount/watch-prune racing publication. Delay delivery across receipt registration, delta commit and retirement; interleave directory and inode notifications and back-to-back replacement cookies. Assert exactly-once accounting and real allowed/refused Auth outcomes. A receipt must never consume another operation's event or let a failed/stale operation clear newer dirtiness. Preserve the one-reader kernel ordering; test userspace scheduling permutations rather than treating arbitrary kernel event reordering as normal. The plan already mentions accounting sequence, watch generations and races at every boundary. These edits turn that general requirement into an auditable contract for the specifically requested two-writes-in-flight case. Today's Auth guard covers uploads (`auth/src/quota.rs:80–127`); the note placement path independently invokes `Prepared::place`, so a common lock cannot be assumed to exist already. 3. **P2 — Make both state layouts explicit merge gates, and state how the default layout gets the typing fix.** Lines 143–146 correctly acknowledge the problem, but leave a central supported configuration unresolved. Require W01/W02/W07/W09 to run separately on (i) an existing default installation with no `--state`, including preexisting DB/WAL/SHM files, and (ii) a separate-state installation. Before accepting the product change, choose and document either a safe state migration with its crash/recovery and charge-preservation rules, or a proven accounting protocol for those in-place DB writes. If the choice is deferred, explicitly keep the product merge blocked for the default layout; a split-state-only typing pass cannot satisfy the fix. Tie those variants to the existing 60-second typing/zero-own-save-R/≤2% gate and exact-charge oracle, and require a W01–W22 evidence checklist on the final product head before product merge. For capacity/known-failure variants, record the actual exercised limit/failure, bounded refusal and measured recovery where recovery is possible; a skipped/unrun cell is missing evidence. Identify which 1M/100-Home cells document unsupported capacity rather than promise successful ≤2-second admission. This preserves the plan's honest limits without letting '?' or an expected failure hide an unexecuted workload. **Own-write suppression assessment** The amendment is substantially stronger than a pathname/time window. An app operation ID is only an application key; it does not identify the writer of a kernel event. The safe part of this design is that completed staging removes legitimate app content MODIFY events from the suppressible set. The receipt then accounts for a narrowly verified namespace/lifecycle transition. Subject to edits 1–2, the requested cases have conservative outcomes: | Scenario | Required interpretation of this plan | |---|---| | Outside truncate/grow or equal-size edit immediately after save | The new inode is already watched. Every MODIFY dirties, even if name, size or mtime later returns to its prior value. Truncation alone can overcount; growth after it is the undercount adversary. Both need the test. | | Outside rename-over/replace | Extra directory move/create/delete events, different inode identity or unmatched cookie revoke the receipt. Never match only the current pathname. | | Outside hard link or old open fd | Ambiguous link topology takes R; an outside content write on a retained alias dirties every owning Home through inode coverage. Do not suppress globally because one owner has a receipt. An unlinked old fd with no counted alias contributes no current name. | | Two app writes in flight | Staging may overlap; publication and accounting must obey edit 2. Distinct operation IDs alone do not provide serialization or a commit order. | | Delayed/coalesced notifications | Admission still fences the one reader. Do not infer event multiplicity from one notification; if a lifecycle sequence cannot be proved, invalidate. Coalescing is not reliably marked with a “coalesced” flag. | | Overflow/watch loss/incarnation reuse | Revoke affected receipts and coverage; dirty all possibly affected Homes; rebuild and fence. No delta-only recovery or provisional admission. | Keep the earlier containment obligations literally operative: raw names and fd-relative no-follow descent, device/mount-ID exclusion and mountinfo readiness, all-owner alias invalidation, watch-incarnation protection, bounded retries/queues, and no admission from fallback/provisional totals. In particular, preserve the anti-vacuity checks: actual configured inode reuse, actual kernel overflow in its explicit test, exact successful reads, and positive allowed Auth admissions after recovery. The old #764 non-linearizable fallback reproducer must continue to refuse. **Three workload spot checks against a506b739** - **W01, typing:** `Prepared::new` closes a flushed image and `Prepared::place` exchanges/places it; the successful callback reaches `usage::wrote`. `Usage::changed` adds a provisional amount and dirties the Home (`usage.rs:528–534`), and ordinary native events also dirty it. Therefore repeated full recounts are a credible explanation of the reported CPU result. D(1) is a proposed outcome, correctly conditional on receipt coverage and the state boundary; it is not current behavior. - **W04, outside 50k import:** the walker uses one `statx` supplying size/type/inode/mount ID per eligible regular name (`scan.rs:82–106, 228–244`). Thus 60k/150k/1.05M regular-file metadata observations per completed pass are consistent with adding 50k to the three initial fixtures. Directory metadata, unknown d_type entries, watch setup and rejected/repeated passes are additional costs. The amendment correctly distinguishes these from one guaranteed pass or an end-to-end latency measurement. Its one-statx description supersedes the older introductory two-call estimate. - **W09, app state:** omitting `--state` assigns `state = data` (`calternal/src/args.rs:169`); notes use `<state>/users/<id>/notes`, including history/meta DBs. The Home walker charges regular names without a SQLite exception. WAL/DB changes therefore invalidate the same Home. Split state avoids those filesystem recounts, but provider logical bytes still need their own generation/failure contract. Existing providers return plain `u64`; that API alone is not the proposed stable provider fence. No additional top-level workload family is needed beyond the 22 rows. The missing mandatory variants are the pre-watch handoff, concurrent receipts/admission, and explicit legacy/split-state gates above. Keep payload bytes and topology as independent fixture dimensions: a tiny-file 100k tree alone cannot qualify long-note autosave, large-photo, sparse, huge-flat-folder or two-disk behavior. Those variants are already called for in the matrix and restart discussion. **Restart and perf-gate assessment** Recommendation (c) is safe and candid. It keeps complete live coverage, refuses unverifiable offline state, does not claim directory/file mtimes prove continuity, rejects “far below quota” as a bound on external growth, and distinguishes a quick 503 from successful admission. Parallel work is a hypothesis to profile, not a promised fourfold gain. A ~15-second starting point still needs a substantial improvement to reach two seconds; the explicit release block if that fails is necessary. Existing 64 KiB enumeration/d_type skipping is correctly acknowledged. Keep the independent flat-folder benchmark because directory-level parallelism does not distribute one huge folder automatically. The gate section already requires perf-test VMs, pinned release heads, all 22 rows at all three sizes, cold/warm repetitions, success/refusal counts, resource/call/fallback measurements and five-minute idle tails. It covers the risky rows in principle. With edit 3's layout variants and evidence/merge checklist, it is enforceable as a pre-product-merge requirement. None of the proposed pass predictions has been independently measured in this design review, and none should be reported as a performance pass merely because this amendment merges.
kayg commented 2026-10-30 04:21:39 +00:00
Author
Owner
Copy link

Applied the three required edits from comment 70235 in 85f4c31c (docs only).

Pin the exact new inode, establish its watch incarnation, then read and validate chargeable size, type, link count and mount/domain identity through the pinned object under coverage.

Keep serialization from receipt registration through the closing fence and accounting commit.

The receipt eligibility, admission visibility and retirement points are explicit; the reader cannot wait for the publication lock. Named tests cover pre-watch growth/truncate/replace, concurrent same/different destinations, save versus real Auth upload, recount/prune races and delayed userspace delivery with kernel ordering preserved.

W01/W02/W07/W09 are separate mandatory gates for an existing default installation (no --state, including preexisting DB/WAL/SHM files) and a split-state installation.

Both layouts require the exact-charge oracle, 60-second typing, zero own-save recounts and ≤2% CPU. Default-layout product merge remains blocked until a documented migration or proven in-place DB accounting protocol passes. Final-head W01–W22 evidence must include exercised capacity/failure and recovery; unrun cells remain missing evidence.

Validation: git diff --check passed; only docs/plans/0754-quota.md changed. No implementation/performance pass claimed.

Applied the three required edits from comment 70235 in 85f4c31c (docs only). > Pin the exact new inode, establish its watch incarnation, then read and validate chargeable size, type, link count and mount/domain identity through the pinned object under coverage. > Keep serialization from receipt registration through the closing fence and accounting commit. The receipt eligibility, admission visibility and retirement points are explicit; the reader cannot wait for the publication lock. Named tests cover pre-watch growth/truncate/replace, concurrent same/different destinations, save versus real Auth upload, recount/prune races and delayed userspace delivery with kernel ordering preserved. > W01/W02/W07/W09 are separate mandatory gates for an existing default installation (no --state, including preexisting DB/WAL/SHM files) and a split-state installation. Both layouts require the exact-charge oracle, 60-second typing, zero own-save recounts and ≤2% CPU. Default-layout product merge remains blocked until a documented migration or proven in-place DB accounting protocol passes. Final-head W01–W22 evidence must include exercised capacity/failure and recovery; unrun cells remain missing evidence. Validation: git diff --check passed; only docs/plans/0754-quota.md changed. No implementation/performance pass claimed.
kayg changed target branch from perf/quota-simple to dev 2026-11-07 19:32:53 +00:00
kayg commented 2026-11-07 19:33:41 +00:00
Author
Owner
Copy link

housekeeping #1009: rebased+green, left open for review.

rebased only quota proposal amendments, excluding WIP #764 implementation; retarget to dev.

head: 56d1abb71d182d45290b28280ae2051e0cdc69e2. rebased onto dev cd7f84432febfc63b788fbb9b9f9950452982d74 and pushed with the original exact force-with-lease.

validation on the Mac VM, through Nix and the shared Mac lock/slot: root bun install --frozen-lockfile; in apps/web, bun run check, bun run lint, bun run build, bun run test; PERF_DIST=<worktree>/apps/web/dist bash perf/web.sh --bundle-only --gate. all passed. this documentation-only branch has no targeted browser specs or Rust implementation changes. exact commands, logs, and dev bundle control.

original-head missing-commit/patch inventory, file pr-769.md.

housekeeping #1009: rebased+green, left open for review. rebased only quota proposal amendments, excluding WIP #764 implementation; retarget to dev. head: `56d1abb71d182d45290b28280ae2051e0cdc69e2`. rebased onto dev `cd7f84432febfc63b788fbb9b9f9950452982d74` and pushed with the original exact force-with-lease. validation on the Mac VM, through Nix and the shared Mac lock/slot: root `bun install --frozen-lockfile`; in `apps/web`, `bun run check`, `bun run lint`, `bun run build`, `bun run test`; `PERF_DIST=<worktree>/apps/web/dist bash perf/web.sh --bundle-only --gate`. all passed. this documentation-only branch has no targeted browser specs or Rust implementation changes. [exact commands, logs, and dev bundle control](https://git.kayg.org/attachments/64244177-fd81-4992-860e-4d5d22ca01cd). [original-head missing-commit/patch inventory](https://git.kayg.org/attachments/fe3c09dc-dea3-47a0-92e2-b44a777083e5), file `pr-769.md`.
Some checks failed
CI / server (pull_request) Successful in 1m17s
Details
CI / rust (pull_request) Failing after 8m33s
Details
CI / web (pull_request) Has been cancelled
Details
Merge conflict checking is in progress. Try again in few moments.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin docs/quota-plan-2:docs/quota-plan-2
git switch docs/quota-plan-2

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch dev
git merge --no-ff docs/quota-plan-2
git switch docs/quota-plan-2
git rebase dev
git switch dev
git merge --ff-only docs/quota-plan-2
git switch docs/quota-plan-2
git rebase dev
git switch dev
git merge --no-ff docs/quota-plan-2
git switch dev
git merge --squash docs/quota-plan-2
git switch dev
git merge --ff-only docs/quota-plan-2
git switch dev
git merge docs/quota-plan-2
git push origin dev
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
backend
Rust server

  
design
Mockups, UI and TASTE

  
docs
ADRs, CONTEXT, TASTE

  
idea
Parked idea, never worked until promoted

  
infra
Deploy, CI, VMs

  
perf
Performance and budgets

  
reliability
Data integrity, corruption traps

  
web
Web client

No labels
backend
design
docs
idea
infra
perf
reliability
web
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
kayg/calternal!769
No description provided.