Pre Release Review

KeeForge Pre-release Review

Review changes before candidate preparation and return actionable findings in chat. This is a static review: do not run tests, builds, compatibility gates, validation scripts, or manual UI/device checks. Do not create a manual test plan or saved report. Source fixes, website edits, issue mutations, commits, and release operations are separate work unless the user requests them. Do not invoke release skills automatically.

Establish the scope

Read repository and local guidance. Resolve the target to a full commit SHA, defaulting to HEAD, and identify the most recent applicable shipped vMAJOR.MINOR.PATCH tag reachable from it. Use release lineage and available release evidence; exclude rc/* tags. An explicit baseline takes precedence. If the baseline is missing, ambiguous, or not an ancestor, clarify it with the user while continuing independent inventory.

Inspect base..target history and the net diff, accounting for reversions and superseded fixes. Group changes by behavior and follow affected callers and contracts. Review committed snapshots; distinguish uncommitted changes and preserve the user's checkout. Read affected folder docs on demand. Include iPhone, iPad, Mac App Store, direct Mac, and both AutoFill extensions where relevant.

Parallel review

Use sub-agents for independent areas when fanout improves coverage or speed, such as behavior risks, test coverage, i18n, and documentation/website consistency. Keep small or tightly coupled reviews in one agent. Establish one baseline and target first; give each agent those exact revisions, any relevant website revision, a bounded scope, and applicable local guidance. All agents follow the same static-only boundary: no tests, builds, manual checks, edits, or saved reports. Ask for actionable findings with source links and material limitations.

The coordinating agent checks findings, resolves contradictions, deduplicates overlap, and reviews contracts spanning assignments. Wait for delegated work or disclose unfinished coverage, then return one consolidated action list in chat.

Review changed behavior and coverage

For each affected behavior, assess concrete risks and the assertions that cover it:

• Data integrity: edits, saves/reopen, conflict recovery, backups, protected fields, unknown XML preservation, and KeePass interoperability.
• Security/privacy: lock and authentication boundaries, secret handling, logging, network egress, permissions, entitlements, and privacy declarations.
• Integration/recovery: extension-safe APIs, target membership, AutoFill allow-lists, minimum OS, platform/channel differences, existing installs, interrupted operations, and relevant performance limits.
• Coverage: success, failure, cancellation, and persistence paths; assertions that prove outcomes; mocks that bypass the relevant behavior; CI selection and skips; UI interactions that unit tests cannot establish.

Explicitly assess compatibility coverage when creation, edits, parsing/writing, or any save path changes, even if the parser/writer did not change. Read test and compatibility guidance as needed. Check foreign-authored input and independent reading of KeeForge output, including preservation after edit/save/reopen. Recommend the smallest useful fixture, scenario, and assertions for a meaningful gap. Existing green tests do not prove new behavior is covered; inspect source and existing CI evidence without running verification. Test consolidation campaigns belong to test-audit.