Resolve the requirements-vs-architecture conflict found in the Phase 5
review. License v1 is frozen at nine fields with no expiry field
(perpetual is a bool; update/rebind policy are opaque labels), so it
cannot express a trial period. The implementation and architecture docs
correctly recorded that boundary, but 02-requirements still listed trial
as a P0 capability and an MVP acceptance criterion.
Decision: trial moves to V1.1.
- 02-requirements: drop trial from the user role and P0 feature list;
acceptance now reads 'authorization state consistent between box and
sub-apps'; add a V1.1 trial row naming the protocol prerequisite; add
a scope row stating perpetual:false is display-only and never expires,
and supports_trial does not grant local trial.
- 00-ai-start-here: remove trial from 'MVP does', add it to 'MVP does
not' with the protocol reason.
- 04-architecture: development order step 5 no longer lists trial/rebind
as MVP work.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Concede two errors in the original review: it cited 01-vision.md for a
'perpetual offline use' promise the vision never makes (only 'offline
verifiable'), and it described the clock-rollback check too broadly -
that check only covers same-list rollback, not an older list paired
with a correspondingly rolled-back clock.
Accept Codex's O5 (verified: StoreRevocations replaces the cache after
signature check with no cross-list monotonicity, so signed revocation
lists can be replayed) and O6, plus four precision refinements. Add the
threat-boundary rationale for O5: monotonicity does not stop a local
attacker but does stop distribution-channel replay, a ~38-day revocation
rollback window is exploitable without any clock control, and benign CDN
staleness alone silently rolls back revocation state - making the
'reject older list' check a correctness requirement, not just hardening.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Code-level audit of the authorization chain: domain-separated machine
hash with no raw identifiers in errors or storage, strict License v1
verification (base64 re-encode round-trip, exact 9-field shape,
timestamp round-trip, machine-hash binding), and revocation state with
clock-rollback defense and revoked-before-expiry ordering. Snapshots to
the UI carry no license ID, signature, path or raw Windows identifiers;
defaults fail closed. Catalog/License/Revocation share one canonical
JSON implementation.
No security defect found. Records two product decisions needed: the
revocation list is a hard dependency for any authorization (missing or
>38-day-old list blocks all launches, in tension with the offline
licensing vision and lacking a distribution plan), and trial is a P0
requirement plus MVP acceptance criterion that is deliberately not
implemented, leaving 02-requirements in conflict with the architecture
and task docs.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Code-level audit of T-401~T-403: launch has no command-injection surface
(AppID-only request, entrypoint must be in recorded installed files,
safepath+JoinUnder+Lstat, no-arg exec.Command and parameterless
ShellExecuteExW), update never force-kills (confirm + natural-exit wait
only), and self-update is journaled, rollback-capable and health-gated
before backup deletion. Confirms Phase 3 O1 is closed by T-401's
preSwitchCheck.
Ruling accepts Codex's follow-up: O4 (self-flagged T-403 fault-injection
and mid-phase Recover test gaps - all four claims verified) and O5
(split assembly prerequisites instead of lumping them under T-502).
Adds a low-cost path to close O4 mostly via the existing DirectorySyncer
seam and filesystem permission tricks, without new production seams.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Adjudicate Codex's review correction: concede three overstatements in
the original review (M3 loop not actually complete - InstallService has
no production assembly and T-401 launch is unbuilt; scope 'no security
defect' to T-302/T-303; O2 mischaracterized - ENOSPC during io.Copy is
misclassified as zip_corrupt with a broken error chain, escalate to P1;
O1 fix was flawed - recheck IsRunning explicitly instead of inferring
app_running from rename failure). Add finding: disk-full surfaces at
write/sync/close with three different codes, so the O2 fix must span the
whole write->sync->close sequence.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Code-level audit of the verified install chain: hash-before-parse and
single-file-handle TOCTOU defenses in verified_package.go, strict
app.json parse cross-checked against the signed Catalog, untrusted
download verified against Catalog Size/SHA256, mandatory non-bypassable
pre-extract disk/running checks, and a complete stable failure-code
enum. No security defect found; records five minor optimizations, the
top being the IsRunning TOCTOU (recheck before the current->backup
rename).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Verify at code level that the Phase 1/2 review findings were actually
closed (not just self-reported): icon cache concurrency + LRU + bounded
fetch (T-606), UI-thread icon delivery (T-607), install durability with
Windows FlushFileBuffers / POSIX dir sync (T-613), ZIP central-directory
preflight (T-612), and catalog signature cross-impl vectors (T-614).
All confirmed real. Records three residuals (R1 real power-loss
validation, R2 per-file fsync cost, R3 singleflight ctx caveat).
Also gitignore *.code-workspace (per review recommendation).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ilaandClaude Fable 5