okrdev/okrs/2026-Q3.md

---
cycle: 2026-Q3
start: 2026-07-23
end: 2026-09-30
status: active
---

<!--
First cycle — a short one. Planning ran 2026-07-23, three weeks into Q3, so this cycle
ends on the normal quarter boundary (~10 weeks) rather than pretending to a full quarter.

No LESSONS.md history exists yet, so targets can't be sandbag-checked against a prior trend —
they're checked against calendar capacity for a solo DRI instead. okrdev has zero adoption
data, so this cycle leans on milestone anchors and one instrumentation KR (KR2.1) rather than
inventing baselines it doesn't have.

DRI load: every KR is Alex, because okrdev is a genuine solo project. The one-DRI-per-KR rule
didn't get evaded here — it's why the plan is only 2 objectives / 5 KRs. A solo DRI can't own
more than that and mean it.
-->

# O1: Turn okrdev from "shipped" into "proven" — evidence from real weeks, not imagined ones
DRI: alex

## KR1.1: Complete one full dogfood cycle on okrdev itself, from this plan to a scored retro
Type: committed
DRI: alex
Confidence: 0.8
Score: —
Notes: Milestone anchors — 0.3 = plan active and parking lot in weekly use; 0.7 = check-ins
  held in ≥6 of the cycle's ~10 weeks; 1.0 = cycle closed with a scored retro and 3 lessons in
  LESSONS.md. The deliverable is the evidence (the scored retro + lessons), not the meetings —
  holding check-ins is the mechanism, not the point. Committed (not aspirational) because this
  is the cycle's whole reason to exist and it's within the DRI's control; confidence starts at
  0.8, not the 0.5 default, precisely because a commitment the DRI controls shouldn't be a coin
  flip — a committed KR sitting at 0.5 is a smell the plan skill tells the coach to flag.

## KR1.2: okrdev installed and run for ≥2 weeks on an outside real project, from 0 to 1 project
Type: aspirational
DRI: alex
Confidence: 0.75
Score: —
Notes: "Outside" = any repo that isn't okrdev — one of the other live projects in ~/Work. The
  ≥2-weeks-of-actual-use bar is what stops this being a launch KR in disguise (install without
  use proves nothing). Aspirational because it depends on the project's own pull, not just
  Alex's discipline.

## KR1.3: Ship friction fixes found by dogfooding, from 0 to 8 method/skill improvements merged
Type: aspirational
DRI: alex
Confidence: 0.7
Score: —
Notes: Each fix must trace to a real chafe point hit in use (a check-in comment, a session
  where a skill misfired) — not speculative polish. This is a count of outputs standing in for
  the outcome "the method chafes less," which isn't measurable this cycle without adoption data
  we don't have. Quality pair: the "docs/skills coherence" health metric — 8 fast fixes must
  not re-introduce the cross-file contradictions the pre-launch review caught.

# O2: Close the gap between "curious" and "parked my first idea"
DRI: alex

## KR2.1: Establish the time-to-first-value baseline — minutes from install to first parked idea
Type: aspirational
DRI: alex
Confidence: 0.6
Score: —
Notes: baseline: unknown — okrdev has never measured its own adoption friction. First-cycle
  instrumentation KR (the allowed exception to outcome-not-output): measure the minutes from
  `/plugin install` to a first parked idea on a clean repo, document the number and where the
  time goes, then cut it. 0.7 = baseline measured and documented; 1.0 = baseline measured and
  the slowest step removed. Can't set a target on a number nobody has yet — establishing it is
  the work.

## KR2.2: A headless install path exists, so adoption isn't gated on the interactive /plugin dialog
Type: aspirational
DRI: alex
Confidence: 0.7
Score: —
Notes: Straight from the parking lot (energy: high) and from this very session — the plugin
  couldn't be installed headlessly, which is exactly the friction a curious adopter hits.
  Milestone anchors — 0.3 = manual steps documented; 0.7 = a script registers the marketplace
  and installs without the TUI; 1.0 = a new user goes clean-repo → Level 0 in under 10 minutes
  following only the README. The 1.0 anchor is usage, not "a script exists," so this launch KR
  stays tied to an outcome and pairs with KR2.1's measurement.

## Health metrics (monitored, not targeted)
| Metric | Red line | Source |
|--------|----------|--------|
| docs/skills cross-file coherence | any reviewer-class contradiction shipped to main and left >1 week | manual coherence pass on the diff (semantic) + the CI `check` job (mechanical) |
| Install footprint | install writes anything beyond `okrdev/` + the marked block in the host agent's instructions file (`CLAUDE.md` for Claude Code, `AGENTS.md` for Codex) (+ opt-in `.github/` at L2) | `git status` after a fresh install |
| Coach nag rate | coach interrupts to classify obviously-maintenance work even once | dogfooding session notes |

Revised: 2026-08-07 — docs/skills cross-file coherence: source gains the CI `check` job
alongside the manual pass. Original source: "manual / a coherence pass on the diff". The red
line is unchanged, and the manual pass is not retired: the checks compare bytes, while the red
line is about *meaning*, so this is additive per the protocol in
[method.md](../../docs/method.md#amendments--the-mid-cycle-change-protocol). The breach that
prompted the automation — the coach block one revision behind its template — was fixed first,
so no line is being renegotiated while red.

Revised: 2026-08-08 — Install footprint: the destination is now named by role rather than by
filename. Original red line: "install writes anything beyond `okrdev/` + the marked CLAUDE.md
block (+ opt-in `.github/` at L2)". The okrdev port to the OpenAI/Codex plugin directory (DRI
override logged in [2026-W32](../checkins/2026-Q3/2026-W32.md)) writes the same marked block,
with the same markers, to `AGENTS.md` — because Codex reads that file and does not read
`CLAUDE.md`. As worded, that identical write was a breach on a technicality. The line is not
being loosened: the budget is still **one** instructions file per install, never both, and the
write count per install is unchanged. `templates/CLAUDE-okrdev.md` contains zero
platform-specific tokens, so nothing about the block itself forks — only its destination.
Mechanized in the same PR at `tests/check.sh` (the destination allowlist) and
`tests/install-footprint.md` (the enumerated table), because a red line whose prose and whose
check disagree is worse than either alone. Note for future readers: check-in rows written
before today quote the original wording. That is the ledger being a record, not drift.