chore: require issue-first workflow, remove plans directory

.agents/README.md

@@ -13,8 +13,6 @@ Agents: start with AGENTS.md, then read the relevant file here before working.
 | `conventions.md` | Coding patterns with examples | Before writing any new code |
 | `design.md` | Visual design spec — colors, typography, spacing, components, interactions | Before implementing or reviewing any UI |
 | `quality.md` | Quality grades per domain, known gaps | When deciding what to improve |
-| `plans/active/` | Current feature plans | Before picking up work |
-| `plans/completed/` | Done plans (context on past decisions) | When you need to understand why something was built a certain way |
 
 ## How Agents Should Use This
 
@@ -23,12 +21,10 @@ Agents: start with AGENTS.md, then read the relevant file here before working.
 3. Read `design.md` before implementing or reviewing any UI.
 4. Read `conventions.md` for coding patterns and examples.
 5. Check `quality.md` to understand current state and known gaps.
-6. Check `plans/active/` for current work in progress.
 
 ## How to update these files
 
 - `architecture.md` — update when adding new system components, changing data model, or making infrastructure decisions
 - `conventions.md` — update when a new coding pattern emerges that should be replicated, or when an anti-pattern is discovered
 - `design.md` — update when introducing a new UI pattern, component variant, or interaction pattern not covered by the existing spec
 - `quality.md` — updated weekly by the Automation Auditor, or manually after significant changes
-- Plans move from `active/` to `completed/` when all issues in the plan are closed

.agents/conventions.md

@@ -373,6 +373,29 @@ test("editor loads on page", async ({ authenticatedPage: page }) => {
 - Authenticated tests require `TEST_USER_EMAIL` and `TEST_USER_PASSWORD` env vars
 - Run before pushing: `pnpm lint && pnpm typecheck && pnpm test && pnpm test:e2e`
 
+## PR Workflow
+
+### Issue-first rule
+
+For `feat` or `fix` PRs, create (or find) a GitHub issue before opening the PR.
+
+```bash
+# Create the issue with status:in-progress so automations don't pick it up
+gh issue create --title "Short description" \
+  --body "## Problem\n\n...\n\n## Acceptance Criteria\n\n- [ ] ..." \
+  --label "feature,status:in-progress"
+
+# Reference it in the PR description
+# First line of PR body: Closes #N
+```
+
+### Label safety
+
+- Use `status:in-progress` on issues you are actively working on.
+- Use `status:backlog` only for issues intended for automation pickup (Feature Builder, Bug Fixer).
+- Never label an issue `status:backlog` if you plan to work on it yourself — the Feature Builder or Bug Fixer may claim it first.
+- Chore PRs (metrics, docs, deps) do not require an issue.
+
 ## Imports
 
 - Use `@/` path alias for all project imports

AGENTS.md

@@ -19,7 +19,7 @@ src/components/ui/ → shadcn/ui components (do not edit)
 src/lib/           → Utilities, types, constants
 src/lib/supabase/  → Supabase clients (client.ts, server.ts, proxy.ts)
 supabase/migrations/ → Database migrations
-.agents/           → Agent knowledge base (architecture, conventions, design, plans)
+.agents/           → Agent knowledge base (architecture, conventions, design)
 .ona/              → Automation definitions and skills
 docs/              → Product spec, decisions
 metrics/           → Daily/weekly metrics snapshots
@@ -35,6 +35,7 @@ metrics/           → Daily/weekly metrics snapshots
 - Named exports only. No default exports.
 - Conventional commits: `feat|fix|chore|docs|test|refactor(scope): description`
 - PRs with type `feat` or `fix` must reference an issue: `Closes #N`. Chore PRs (metrics, docs, deps) do not require an issue.
+- **Issue-first workflow:** Before creating a `feat` or `fix` PR, create a GitHub issue first (or find an existing one). Label it `status:in-progress` immediately. Add `Closes #N` to the PR description. This prevents the PR Reviewer from blocking the merge.
 - Database changes require a migration: `npx supabase migration new <name>`
 - Environment variables: `NEXT_PUBLIC_` prefix only for browser-safe values.
 
@@ -82,14 +83,18 @@ Issues use labels for status, priority, and flags:
 
 Label lifecycle: `status:backlog` → `status:in-progress` → `status:in-review` → `status:done`
 
+### Label rules to avoid automation conflicts
+
+- `status:backlog` — **only** for issues you want automations (Feature Builder, Bug Fixer) to pick up. These automations poll for `status:backlog` issues on a cron schedule.
+- `status:in-progress` — use when creating an issue for work you are already doing. This prevents automations from picking it up.
+- Never create an issue with `status:backlog` if you intend to work on it yourself — use `status:in-progress` instead.
+
 ## Where to Find Details
 
 - Architecture and data flow: `.agents/architecture.md`
 - Design spec (colors, typography, spacing, components, interactions): `.agents/design.md`
 - Coding patterns and conventions: `.agents/conventions.md`
 - Quality status per domain: `.agents/quality.md`
-- Active plans: `.agents/plans/active/`
-- Completed plans: `.agents/plans/completed/`
 - Product specification: `docs/product-spec.md`
 
 ## Next.js