f83ec8169c
Five self-contained work briefs in a new docs/plans/junie/ subdirectory, each tagged against a numbered item in docs/TODO.md so Junie can take them independently in any order. 02-k3s-prole-rename.md -> queue #2 (drift R5) 06-patch-garage-script-fixes.md -> queue #6 (drift R9) 07-init-cnpg-gke-sa-wiring.md -> queue #7 (drift R8) 13-podmonitor-manual-management.md-> queue #13 15-remove-dead-dashboard-consumer.md-> queue #15 Each brief follows the same shape: Why -> What changes (concrete file paths + line numbers + before/after) -> Verification -> Out of scope -> Commit shape -> Definition of done. The intent is that Junie reads cold (no shared chat history) and lands the change without escalating questions. Also adds: - docs/plans/junie/README.md describing the convention. - Row in docs/plans/README.md so newcomers find the subdirectory. - Brief reference + "Assigned to Junie" tag on each of the five queue items in docs/TODO.md. Existing in-progress assignment to Junie (Phase 2 pg_oauth) is unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3.1 KiB
Junie briefs
Self-contained, single-task briefs for Junie to consume from inside the IntelliJ IDE. Each file is a hand-off — Junie reads the brief cold (no shared chat history), implements the change, and opens an MR.
What lives here vs. ../
The .. parent directory holds architectural plans — multi-section
documents covering an initiative's strategy, schema, and component design.
They outlive the implementation and become the architectural reference
once shipped.
This subdirectory holds work briefs — smaller, more tactical, scoped
to a single MR's worth of changes. They reference the master TODO index
(../../TODO.md) and contain enough context for Junie to land the change
without escalating questions.
Brief shape (convention)
Each brief follows this skeleton:
- Why — one or two paragraphs of context, including the trigger event if any (e.g. "the 4/28 14:00 UTC outage").
- What changes — concrete file paths, line numbers, before/after where useful. Don't make Junie re-derive the change.
- Verification — runnable commands or
helm templatediffs that confirm the change. Each brief ends with a Definition of done checklist. - Out of scope — explicit fences. The TODO is interconnected; without this section briefs creep.
- Commit shape — proposed commit message + structure.
Status tracking
Every brief here corresponds to a numbered item in
../../TODO.md (or has an explicit "doesn't yet exist
in TODO" note). When Junie lands a brief:
- Move the corresponding item from the TODO ranked queue into the Done section with date + commit ref (or the convention used by the rest of the file).
- Don't delete the brief from this directory — it stays as the design record.
Current briefs (as of 2026-05-01)
| File | Queue # | Subject |
|---|---|---|
02-k3s-prole-rename.md |
#2 | Rename k3s prole-*.yaml → knoe-*.yaml (kustomize is broken) |
06-patch-garage-script-fixes.md |
#6 | Three defects in scripts/patch_garage_cross_cluster.sh |
07-init-cnpg-gke-sa-wiring.md |
#7 | Wire cnpg-backup-sa into CNPG cluster spec; bump operator to v1.29 |
13-podmonitor-manual-management.md |
#13 | Migrate off CNPG-deprecated enablePodMonitor + podMonitorRelabelings |
15-remove-dead-dashboard-consumer.md |
#15 | Remove dead Kong DASHBOARD consumer + basicauth_credentials |
How a session fires off a batch
The driving session (Claude Code, Cowork+Code, or a human) writes the briefs into this directory and points Junie at one or more of them. Junie reads the brief, implements, runs the verification checklist, opens an MR. Each brief is independent — Junie can take them in any order, or in parallel across separate IDE sessions.
The brief is the contract. If something is unclear, the brief is buggy and should be edited before Junie continues.