v1.7.0 — pi-plan-build

Security at every stage: the standards assume abuse, the spec states the threats, and the review gets an attacker.

• An attacker pass joins the review on sensitive ground. When the spec has Threats, or the changed files or diff touch authentication, sessions, permissions, credentials, crypto, payments, uploads, redirects and the like, a second fresh call gets one job: break the change. It checks every entry point the change adds or alters as someone who controls the input, holds a stolen or another user's session, replays or automates requests and guesses ids: authorization per object, what each state change requires the caller to prove, logic reused from another flow that lost its preconditions, injection, leaks, missing limits, permissions in migrations. Its findings ("Security: …") get the same second look as the rest. reviewer.security: auto (default, deliberately broad), always, off.
• Threats in the spec. A change that adds or alters an entry point or touches a trust boundary gets a ## Threats section (who can reach it and with what, what they must prove, how it could be abused, what prevents it), and its acceptance criteria include the abuse cases.
• A security line in the default standards. Assume every entry point will be abused; each operation checks who the caller is, what they may act on and what they have proven; reused logic keeps its preconditions; security-relevant changes get abuse-case tests. Existing AGENTS.md sections aren't changed: add the line yourself.

Full list: CHANGELOG.md