Changelog - Dev - 07.14.2026

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog.

---

[Unreleased] - 2026-07-14

Added

• Lantern CLI and agent config restructure: Introduces a new lantern dev CLI and restructures the .agents/ config hierarchy with centralized rule management under .agents/rules/. Rules are now compiled into AGENTS.md via npm run sync:agents, improving maintainability and consistency across agent instructions. (#655) enhancement devops

Fixed

• Stage C safety code-review remediation: A local max-effort review of the block/report/appeal flow and the sealed-ban backend fixed a cluster of correctness issues. Backend (auth API): the appellant appeal cap is consumed only after a real restriction is confirmed (and the doc-upload cap only after validation), a closed appeal rejects new replies (409), appeal adjudication is transactional and claim-then-act so a concurrent reclaim/reinstate cannot diverge, the permanent-reinstate rationale is also gated on the linked account's ban duration, the recycled-number reclaim aging floor checks the freshest active ban, and /unban-phone clears every row in one pass. Client (web): the FCM service worker registers at its own scope instead of clobbering the PWA worker, a notificationclick handler opens the app, report evidence is labeled with its real type and dropped attachments are counted, the block-to-report flow is guarded against a double-complete (backdrop/Escape ignored mid-submit), and the appeal Escape handling, file-input reset, and block-reason focus ring are fixed. Admin: the enforcement history now includes appeal reinstatements. Residual follow-ups filed as #664, #665, #666, #667, #668. Closes #662. bug

Security

• Sealed-login cross-account ban lift closed: In the sealed (Stage B) POST /auth/phone/token pairing, the PIN proof was verified only against the auth_lookup row for the token's phone number, never the body userId's own authProofHash, so a valid proof for one sealed account could drive the reinstate and ban-axis logic against a different account whose PIN was never proven. The pairing now binds to the body account (the identical gate token issuance enforces to mint). The follow-on sealed-account PIN brute-force lockout is deferred to the sealing rollout (#663). Dormant on dev (sealing not enabled); recorded in SECURITY_REMEDIATION.md. security