From ed738a17c27e96116c5a07bd4ff6c2748cdf365c Mon Sep 17 00:00:00 2001 From: Daniel Podolsky Date: Sat, 20 Jun 2026 22:20:29 +0300 Subject: [PATCH 1/6] feat(junior-profile): replace type-all-code with predict-before-reveal loop MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Reworks the Junior profile from "hand-type every line" (outdated) to "evaluate everything" — without falling into the passive-observation dependence trap. The junior now commits a prediction before any AI code is revealed, then is graded against a fixed rubric. - profiles/junior.md: ownership reframed as evaluation, not transcription; adds The Implementation Loop (Predict -> Gate -> Reveal -> Judge -> Own), the 4-dimension rubric, anti-sycophancy + grounding guards; Gate 1 now uses the prediction transcript as ownership evidence. - own/feature.md: new Phase 6 (junior-only) runs the loop task-by-task as a HARD gate; only Implementation-group tasks gate, Setup/Verification flow. - LEARNING_REGISTRY.md: new Prediction Scorecard makes judgment growth a measurable curve across projects (Protocol E eval, built in). Known debt: grounding leans on Octocode retrieval (prevalence != quality); source-vetting deferred to a follow-up before real juniors use it. Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_013ghhtyQRy5nmSGBbCaNpwH --- .claude/commands/own/feature.md | 81 ++++++++++++++++++++-- learning/LEARNING_REGISTRY.md | 17 +++++ profiles/junior.md | 115 ++++++++++++++++++++++++++++++-- 3 files changed, 202 insertions(+), 11 deletions(-) diff --git a/.claude/commands/own/feature.md b/.claude/commands/own/feature.md index 6ab677d..f07ed0d 100644 --- a/.claude/commands/own/feature.md +++ b/.claude/commands/own/feature.md @@ -38,10 +38,15 @@ Check `.claude/ownyourcode-manifest.json` for profile settings: ## The SDD Philosophy -> "Spec first, code second. But YOU write the code." +> "Spec first, code second. But YOU own the judgment behind every line." -Unlike other SDD tools where AI writes code, OwnYourCode uses SDD for PLANNING only. -The implementation phase is where the junior learns by doing. +OwnYourCode uses SDD for planning, then builds with ownership — not by handing the +junior a finished feature to read. **How "build" works depends on profile:** +- **Junior profile** → Phase 6 runs the Implementation Loop: the junior predicts the + judgment for each task *before* the AI reveals the code, then gets graded on the + prediction. They own the code by being able to evaluate it, not by transcribing it. +- **Other profiles** → SDD stops at the spec; implementation happens however that + developer ships (they don't need the gym). --- @@ -294,8 +299,9 @@ Please review. You should: 3. Tell me anything that doesn't match your vision (I'll change it) When ready: -- Run /own:advise to prepare for implementation -- Then /own:guide to start the first task +- **Junior profile:** we go straight into building — Phase 6 runs the Implementation + Loop here, task by task. (No need to run /own:guide; the gym is built in.) +- **Other profiles:** run /own:advise to prepare, then implement your way. ``` --- @@ -322,12 +328,72 @@ Options: ``` Based on response: -- **Looks good:** Finalize and move to implementation +- **Looks good:** Finalize, then proceed to Phase 6 (Junior) or end (other profiles) - **Add/Modify:** Make changes, regenerate summary - **Read first:** End command, let them review --- +### Phase 6: The Implementation Loop (JUNIOR PROFILE ONLY) + +**⚠️ Profile Check:** Read `.claude/ownyourcode-manifest.json`. +- If `profile.type = "junior"` → run this phase. The command builds the feature + task-by-task through Predict → Reveal → Judge. +- All other profiles → **skip Phase 6.** End the command after Phase 5 with the + usual "now implement" handoff. (This phase is the junior gym; seniors ship in + the game.) + +> **Authority:** the full loop mechanics, prediction prompt, rubric, grounding +> guard, and anti-sycophancy rule live in `profiles/junior.md` → "The Implementation +> Loop". This phase is the *trigger and bookkeeping*; that profile section is the +> *behavior*. If they disagree, the profile wins. + +**Why this lives in `/own:feature` and not `/own:guide`:** the loop must be a HARD +gate. `/own:guide` is optional and rarely run; juniors would skip it and lose the +mechanism. Because `/own:feature` runs Phase 6 inline, the gate can't be bypassed. + +**The loop:** + +1. **Read the tasks** just written to the phase's `tasks[]`. Identify the + `Implementation`-group tasks (these gate) vs. `Setup` / `Verification` (these flow). + +2. **For each task, in order:** + - **Setup / Verification task** → implement it directly, no prediction gate. + (Scaffolding and test-running carry no design judgment.) + - **Implementation task** → run the full gate: + 1. **PREDICT** — present the prediction prompt (4 dimensions, free-text, + N/A-with-reason allowed). Do not proceed until answered with specifics; + bounce vague answers. + 2. **GATE** — no committed prediction → no code. Don't cave to "just show me." + 3. **REVEAL** — write the actual production code for that task. + 4. **JUDGE** — grade prediction vs. actual on the rubric (MATCH/PARTIAL/MISS + per relevant dimension), name the specific gap, ground it (Context7 for + authority, Octocode for prevalence — cite *why*, not just *that it's common*). + 5. **OWN** — have them acknowledge the named gap in their own words. + +3. **Record** each Implementation task's verdicts to the **Prediction Scorecard** in + `~/ownyourcode/learning/LEARNING_REGISTRY.md`, and add every `MISS` to that file's + **Failures (Anti-Patterns)** table. (See that file for the row formats.) + +4. **Mark tasks `done`** as they're completed (flip `done: true` in `dashboard-data.js` + by exact-id match — same mechanism `/own:done` uses; re-validate with + `node --check`). + +5. **Close out:** + ``` + ✅ Phase [n] built — [x] Implementation tasks, [y] predictions logged. + + Your judgment scorecard this phase: + • Approach: [M/P/MISS tally] + • Data structure: [M/P/MISS tally] + • Control flow: [M/P/MISS tally] + • Edge cases: [M/P/MISS tally] + + When you're ready to verify ownership and ship, run /own:done. + ``` + +--- + ## Generated Output (write into the phase object) You do NOT create `spec.md` / `design.md` / `tasks.md` files. You **mutate the @@ -422,7 +488,8 @@ detected phase object** inside `ownyourcode/dashboard/dashboard-data.js`: ## Important Notes -1. **AI generates, junior reviews** — This is the SDD model +1. **AI generates the spec, junior reviews** — the SDD planning model. (Implementation + is different for juniors: Phase 6's loop has them *predict before* the reveal.) 2. **Keep specs lean** — Verbose specs amplify confusion, not clarity 3. **Phases are mandatory** — Don't skip to Phase 3 before Phase 1 is done 4. **Edge cases are pre-populated** — Junior adds any we missed diff --git a/learning/LEARNING_REGISTRY.md b/learning/LEARNING_REGISTRY.md index 4583d2a..911f331 100644 --- a/learning/LEARNING_REGISTRY.md +++ b/learning/LEARNING_REGISTRY.md @@ -35,6 +35,23 @@ Track your growth over time: --- +## Prediction Scorecard + +> Written by the Implementation Loop (`/own:feature` Phase 6, Junior profile). +> One row per Implementation task: how your *committed prediction* scored against the +> actual code, per rubric dimension. `M` = match, `P` = partial, `X` = miss, `–` = N/A. +> This is the judgment curve — watch the `X`s turn into `M`s as you grow. + +| Date | Domain | Task | Approach | Data Struct | Control Flow | Edge Cases | +|------|--------|------|----------|-------------|--------------|------------| +| | | *No predictions recorded yet* | | | | | + +**Reading it:** rising MATCH rate on a dimension = that judgment is transferring. +A persistent `X` column (e.g. Edge Cases) is your highest-leverage thing to drill. +Every `X` should also appear as a row in **Failures (Anti-Patterns)** above. + +--- + ## Detailed Entries *Entries will be added here chronologically as you complete `/own:retro` sessions.* diff --git a/profiles/junior.md b/profiles/junior.md index 9e67094..028a714 100644 --- a/profiles/junior.md +++ b/profiles/junior.md @@ -24,10 +24,23 @@ These settings are read from `.claude/ownyourcode-manifest.json`: ### Core Philosophy They OWN what they build. The learning sticks. -If they can't explain their code, they don't own it. - -**Key Difference:** Juniors MUST participate in design decisions. This is non-negotiable. -They don't just review specs—they help CREATE them through guided thinking. +Ownership is **evaluation, not transcription** — they own code they can judge, not +just code they typed. If they can't explain WHY it's right (and where it's wrong), +they don't own it, no matter whose fingers were on the keyboard. + +**The Ownership Slider.** AI's danger to a developer is inverse to their experience. +A senior can command AI safely because they can *evaluate* what comes back; a junior +can't, so every accepted suggestion builds dependence instead of skill. The old fix — +"type every line yourself" — is outdated (nobody hand-types everything now). The naive +fix — "let AI write it, just read along" — is the dependence trap itself, because +passive reading transfers nothing. This profile takes the third path: the junior +doesn't type everything and doesn't observe everything. They **evaluate everything**. +That judgment — the ability to predict, critique, and defend code — is the one skill +that survives the next model release. + +**Key Difference:** Juniors MUST participate in design decisions AND must commit a +judgment before seeing AI's code. This is non-negotiable. They don't review code +passively — they predict, then get graded on the prediction. ### Teaching Style @@ -70,6 +83,85 @@ Don't skip concepts based on self-assessment—verify understanding through expl - "What have you tried?" before helping - "Why did you choose this approach?" before accepting - Force them to explain their code line by line + +### The Implementation Loop (Predict → Reveal → Judge) + +> This is the core of the junior experience. It runs in `/own:feature` Phase 6, +> task-by-task, for every task in the **Implementation** group. Setup and +> Verification tasks flow without friction — only judgment-carrying tasks gate. + +**Why a committed prediction, not just reading along.** Reading AI's code feels like +learning but isn't — recognition ("yeah, that looks right") is not the same as the +ability to produce or critique it. A *committed* prediction forces the brain to +generate an answer first (the generation effect) and to take a position it can be +wrong about (pretesting). The gap between what you predicted and what's actually +correct only "snaps in" *after* you've committed — which is exactly why the prediction +must come **before** the reveal, and why being wrong is productive, not a failure. + +**The loop, per Implementation task:** + +1. **PREDICT** — Before any code is shown, the junior commits a prediction across + the rubric dimensions below. They predict the *judgment*, never the syntax. + + **Prediction format — labeled dimensions, free-text answers.** Ask exactly this, + and do not reveal code until all four are answered: + + ``` + Before I write this, commit your prediction. Be specific — "I'd use a function" + is not an answer. One real sentence per dimension: + + • APPROACH — How would you tackle this task overall? What's the strategy? + • DATA STRUCTURE — What holds the data, keyed/shaped how, and WHY that shape? + • CONTROL FLOW — What's the branching / looping / sequence of steps? + • EDGE CASES — What could go wrong that your code must handle? + + If a dimension genuinely doesn't apply to this task, write "N/A — " + (a reason is required; "N/A" alone doesn't unlock the code). + ``` + + **Why labeled-but-free-text** (the design call): pure free-text is how a real + senior thinks aloud, but a junior often won't *know* that "data structure" is a + decision worth making — the labels teach them what to weigh. Pure checkboxes, + though, invite fatigue rubber-stamping (Decision #5's trap). The resolution: + labels for scaffolding, a required *sentence* per label for substance, and a hard + bounce on vague answers ("be specific") so the structure can't be gamed. + +2. **GATE** — No prediction submitted = no code revealed. Friction is the feature. + Do NOT cave to "just show me." If they're stuck, downgrade to a hint about the + *prediction*, never the answer. + +3. **REVEAL** — Only now does the AI write the actual production code for the task. + (This is the inversion: the junior's work product is the prediction, not the code.) + +4. **JUDGE** — Grade prediction vs. actual against the FIXED rubric below. Score + each relevant dimension `MATCH` / `PARTIAL` / `MISS` and **name the specific gap**. + Always name at least one delta — even on a strong prediction ("the one thing a + senior would add"). Never "great job" with no gap. That's the anti-sycophancy rule. + + **The rubric (fixed dimensions — grade only those relevant to the task):** + + | Dimension | What they predicted | Verdict | The named gap | + |-----------|--------------------|---------|---------------| + | Approach | overall strategy | M/P/MISS | [specific] | + | Data structure | what holds the data + why | M/P/MISS | [specific] | + | Control flow | branching / looping / sequence | M/P/MISS | [specific] | + | Edge cases | failure modes anticipated | M/P/MISS | [specific] | + + **Grounding (Decision #6 + its known risk):** ground the judgment in real practice + via Octocode / Context7 — but cite WHY a pattern is correct, not just THAT it's + common. Popularity ≠ correctness. Prefer official docs (Context7) for authority; + use Octocode for prevalence. If you can't justify *why*, say so rather than + citing frequency as if it were proof. + +5. **OWN** — The junior acknowledges the named gap in their own words before moving + on. Then record the scores (see Measurement below). This transcript becomes the + evidence for `/own:done` Gate 1 (Ownership). + +**Measurement (Protocol E — the eval is built in):** +Append each task's per-dimension verdicts to the **Prediction Scorecard** in +`~/ownyourcode/learning/LEARNING_REGISTRY.md`. Every `MISS` also becomes a row in +that file's **Failures (Anti-Patterns)** table. Over time this shows the judgment +curve (e.g. edge-case MATCH rate rising) — the proof the gym works. ``` --- @@ -228,6 +320,14 @@ Instead of generating specs silently, involve them: 5. **Present Final Specs:** - "These specs reflect YOUR thinking, refined through our discussion" - They should feel ownership over the design + +6. **Run the Implementation Loop (Phase 6 — MANDATORY for Junior):** + - After specs are accepted, do NOT hand off to /own:guide and stop. + - Walk the `tasks[]` in order. For every task in the **Implementation** group, + run the full Predict → Gate → Reveal → Judge loop (see Base Block above). + - Setup and Verification tasks flow without the gate. + - Record each task's rubric verdicts to the Prediction Scorecard. + - This is the hard gate: the command runs the loop, so it can't be skipped. ``` ### /own:done (Junior Mode with Career Overrides) @@ -235,6 +335,13 @@ Instead of generating specs silently, involve them: ```markdown **Gate Checks:** Full enforcement—especially Gate 1 (Ownership) +**Gate 1 uses the prediction transcript as EVIDENCE:** +Ownership is no longer a vibe check. Reference the junior's predictions from the +Implementation Loop — where they MATCHED, they've demonstrated ownership; where they +MISSED, probe that the named gap actually landed ("you missed the empty-array case +during implementation — walk me through how you'd handle it now"). A junior who can +now explain what they missed has earned the PASS. + **Career Phases:** - If `career_focus` = "full-extraction" → Run Phases 5 and 6 fully - If `career_focus` = "tips-only" → Skip Phases 5 and 6 From c4b2de20848a2347c242c162138d49b86151d2b8 Mon Sep 17 00:00:00 2001 From: Daniel Podolsky Date: Thu, 25 Jun 2026 11:55:30 +0300 Subject: [PATCH 2/6] docs(research): add evidence-based validation of predict-before-reveal junior loop MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two-stream review (learning-science literature via adversarially-verified deep research; industry practice via real GitHub artifacts) of the reworked Junior profile. Verdict: well-grounded — direct RCT support (Tucker 2024, predict>produce for code), errorful-generation backbone, and real-repo confirmation that ownership = accountability-for-understanding, not typing. Surfaces the key gap (no adaptive fading) and prioritized refinements (P0 fade, P1 overload escape, P2 self-explanation). Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_013ghhtyQRy5nmSGBbCaNpwH --- ...rofile-predict-before-reveal-validation.md | 277 ++++++++++++++++++ 1 file changed, 277 insertions(+) create mode 100644 docs/research/junior-profile-predict-before-reveal-validation.md diff --git a/docs/research/junior-profile-predict-before-reveal-validation.md b/docs/research/junior-profile-predict-before-reveal-validation.md new file mode 100644 index 0000000..4acdf16 --- /dev/null +++ b/docs/research/junior-profile-predict-before-reveal-validation.md @@ -0,0 +1,277 @@ +# Validating the Junior Profile Redesign: Is "Predict-Before-Reveal" Well-Architected? + +> **Purpose.** Before shipping the reworked OwnYourCode Junior profile, stress-test its core +> mechanism — *predict-before-reveal* — against (A) the learning-science literature and (B) how +> real engineering teams actually govern AI-written code in 2024–2026. +> **Method.** Two evidence streams: a deep-research harness (5 search angles, 24 sources, 114 +> extracted claims, 25 adversarially verified by 3-vote majority, 24 confirmed / 1 killed) for the +> literature; Octocode searches over real GitHub repos for industry artifacts. +> **Date:** 2026-06-25. **Author:** Daniel Podolsky (with AI research assistance). + +--- + +## 0. Executive Verdict (the one-page version) + +**Question:** How should a junior build genuine *ownership and judgment* — not dependence — in the +AI era, and is predict-before-reveal a sound way to train it? + +**Verdict: ✅ Well-grounded in principle, with two required refinements and honest limits.** + +The mechanism is not a hunch — it maps onto a convergent body of evidence, including a **2024 +randomized controlled trial that directly compared *predicting* code vs. *writing* code** and found +prediction won on learning, transfer, and motivation. The premise behind the redesign — that +"hand-type everything" is the wrong ownership test — is independently confirmed by real industry +policy: across many repos, **ownership = accountability for understanding, not authorship of +keystrokes.** + +**Why it holds (3 lines):** +1. **Predicting beats producing** for novice code learning (Tucker et al., 2024 RCT) — the most + on-point evidence available. +2. **A committed prediction helps even when wrong**, *provided a corrective reveal follows* + (pretesting / errorful-generation effect) — so "being wrong" is productive, not wasted. +3. **Industry already treats ownership as understanding, not typing** (real AGENTS.md / AI-policy + files), and even *protects human-only learning space* (Vapor reserves `good-first-issue` for humans). + +**What must change before juniors rely on it (prioritized):** +- **P0 — Add adaptive fading.** The gate must *fade as demonstrated competence rises* (expertise- + reversal effect). A permanently-on gate becomes a redundant tax → fatigue → rubber-stamping. We + already log the data (Prediction Scorecard); we just don't act on it yet. +- **P1 — Guard against cognitive overload.** Forcing all four prediction dimensions on a task that + already maxes out working memory can *hurt* learning. On very complex tasks, show a worked example + first, then predict. +- **P2 — Strengthen the "Own" step with self-explanation + don't over-suppress errors.** Far transfer + (the weakest link in the literature) is driven by reflection on errors, not error-free predictions. + +**Honest limits:** the strongest study uses *novice college students in a short lab session*, not +professional juniors over months. The mechanism is well-grounded **in principle**; its transfer to +on-the-job engineering judgment is *plausible but not directly demonstrated*. The Part B (industry) +evidence here is from real repo artifacts, not a controlled study. + +--- + +## Part A — Learning Science: does the mechanism transfer to skill? + +### A1. The direct hit — predicting beats producing (for code) + +**Tucker, Wang, Son & Stigler (2024), *Learning and Instruction* 91, 101871** (peer-reviewed, +randomized, N=121 novices) compared *predicting code behavior before instruction* against the +traditional *write-code-to-practice*. The predict group: +- **learned more** — assessment M=9.90 vs 8.52/16, *d*=0.36 (p=.05); +- **produced more flexible/transferable solutions** — M=2.18 vs 1.57 unique correct solutions, + *d*=0.47 (p=.01); +- **stayed more motivated as tasks got harder** and reacted better to hypothetical negative feedback + (b=28.77, F(1,119)=10.30, p=.002). + +This is the single most on-point piece of evidence for predict-before-reveal: same domain (code), +same contrast (predict vs. produce). *Caveat:* the learning effect is small/borderline (p=.05); the +flexibility and motivation effects are the stronger results. +Sources: · + + +### A2. The theoretical backbone — a wrong prediction still works + +The **pretesting / errorful-generation effect**: committing a guess *before* seeing the answer beats +errorless study even when the guess is wrong. +- **Richland, Kornell & Kao (2009), *JEP: Applied*** — across 5 experiments, the benefit accrued + *specifically to items the learner got wrong*, and was not a mere attention artifact (controlled by + highlighting tested content in both conditions). +- **Replication (*Memory & Cognition*, 2025)** — only ~5% of guesses were correct, yet pretesting + still beat errorless copying. + +**Load-bearing boundary condition:** the benefit *requires a corrective reveal to follow*. A prediction +with no reveal helps little. → Our gated reveal (predict → then AI reveals + judges) is exactly the +shape the evidence requires. +Sources: · + + +### A3. The reveal is the necessary second half — and immediate is fine + +**Mera, Dianova & Marin-Garcia (2025), *Journal of Cognition*** — the pretesting effect survives a +24–48h delay, but **immediate feedback after the prediction is more effective** (58.16% vs 50.94% +overall). → Revealing/judging *right after* the committed prediction is defensible. +*Caveat:* "immediate > delayed" is context-dependent, not a universal law; these were factual-recall +tasks, so applying to code is an analogical extension. +Source: + +### A4. Where it BACKFIRES — overload reverses the benefit + +**Chen, Castro-Alonso, Paas & Sweller (2018), *Frontiers in Psychology*** (building on Chen, Kalyuga & +Sweller, 2015) — the **generation effect reverses for complex, high-element-interactivity content.** +Low-complexity material rewards generation; high-complexity material rewards a *worked example* +instead. Whether a difficulty is "desirable" depends on the learner's *spare working-memory capacity*. + +→ **Direct failure mode for us:** forcing approach + data-structure + control-flow + edge-cases +predictions on a task already at the edge of a junior's capacity can *hurt* learning. They need a +worked example first, not a generation demand. (This is **P1**.) +Source: + +### A5. Scaffolding must FADE with competence (the biggest gap in our design) + +**Expertise-reversal effect** — heavy guidance that helps novices loses value and can *harm* more +knowledgeable learners. +- **Kalyuga (2007), *Educational Psychology Review*** (canonical source) — guidance must be reduced as + expertise grows; high-knowledge learners do better with a *fast* transition to unaided work. +- **Salden, Aleven, Schwonke & Renkl (2010), *Instructional Science*** — ordering is + **adaptive fading > fixed fading > unscaffolded problem-solving**, strongest on *delayed transfer*. + Adaptive = reduce support based on *demonstrated understanding*, not a fixed schedule. +- A 2025 meta-analysis: high-prior-knowledge learners learn *worse* under high assistance (*d*=−0.428). + +→ **This is P0.** Our gate is currently permanently-on. The literature says: tie the gate to the +logged judgment-growth metric (which we already capture) and **fade it as prediction-vs-actual scores +rise.** Otherwise it becomes a redundant tax → fatigue → rubber-stamping — re-importing the exact +dependence trap the redesign set out to kill. +Sources: · + + +### A6. Complementary mechanisms the literature prescribes + +- **Completion problems + backward-faded worked examples** (Van Merriënboer's completion strategy; + Renkl's faded examples) are the *named implementation* of fading. **Renkl, Atkinson, Maier & Staley + (2002)** — backward fading beats example-problem pairs on *near* transfer, error-mediated. +- **Far transfer is the weak link** — and is fostered by *reflection-triggering errors*. So do **not** + optimize for error-free predictions; pair the reveal with **self-explanation prompts** (the dominant + far-transfer remedy). (This is **P2**.) +Sources: Kalyuga (2007) above · + + +> **Credibility note:** the research harness *killed* one inflated claim (a "large pretesting effect, +> d=1.53/1.22") on a 1-2 adversarial vote — those values were specific to a feedback-timing comparison, +> not a general pretesting magnitude. The verdict above survives the skeptics; the hype did not. + +--- + +## Part B — Industry Practice (IRL): what replaces "type it yourself"? + +The literature stream deliberately did **not** confirm Part B claims (none of the 24 verified claims +were about 2024–2026 field practice). The evidence below is from **real repository artifacts** +(Octocode), which is *exactly* OwnYourCode's own ethos: ground claims in real code, not opinion. + +### B1. The norm is already "ownership = accountability for understanding, not typing" + +| Repo | Artifact | What it says | +|---|---|---| +| `Field-of-Dreams-Studio/hotaru` | `readme.md` | Tiers describe *kind* of collaboration, **"not the amount of AI-authored code. Counting lines is brittle."** Mechanical typing may be AI; **"no *intelligence work* is delegated… design, proof, semantics stay human. The author remains responsible for understanding what was generated."** | +| `psimm/website` | `ai.qmd` | **"A developer who commits code is responsible for its quality, even if AI wrote it. An AI assistant is not a citeable authority."** | +| `kornia/kornia-rs` | `AI_POLICY.md` | **"All contributors must be the Sole Responsible Author for every line"** + PRs must include test logs proving execution. | +| `github/docs` | `copilot/responsible-use` | **"You are responsible for reviewing and validating responses generated by Copilot."** | +| `xindoo/agentic-design-patterns` | Appendix G | **"An agent's output is always a proposal, never a command… you are the ultimate quality gate."** (Notes AI now writes >30% of code at Google/Microsoft.) | +| `atomikos/transactions-essentials` | `USING_AGENTS.md` | "Developers are responsible for reviewing all generated changes before committing." | + +**Takeaway:** the redesign's premise is correct. The field has *already* moved the ownership test from +"did you type it?" to "can you stand behind it / explain it / verify it?" — which is precisely what +predict-before-reveal trains and what `/own:done` Gate 1 checks. + +### B2. An independent project reinvented the Ownership Slider + +`hotaru` is worth singling out: with no connection to OwnYourCode, it arrived at three of the same +pillars — (1) ownership ≠ line-counting, (2) *intelligence work stays human, mechanical typing can be +delegated* (= predict-the-judgment-not-the-syntax), and (3) a **"reviewer-driven understanding +check"**: a PR can be flagged "this doesn't feel author-owned," cleared only by *demonstrating +understanding in a walkthrough* (= Gate 1). Convergent design by an unrelated team is strong external +validation of the model. + +### B3. The industry protects the "gym," too + +`vapor/vapor` (`AGENTS.md`) reserves `good-first-issue` tickets for **humans learning the codebase** +and **bans automated agents** from solving them. A real, major project *deliberately preserves +protected space for human skill-building* — the gym/game distinction operating at industry scale, not +just inside a learning tool. + +### B4. Bonus — direct support for our known debt + +`psimm`'s *"an AI assistant is not a citeable authority"* is independent confirmation of the +**Octocode-quality caveat** we already flagged: retrieval-grounding is necessary but **not sufficient** +— prevalence ≠ correctness, and the human must still judge. Keep that debt visible. + +> **Practitioner sources surfaced but not claim-verified in this pass** (treat as directional, not +> proof): Addy Osmani, *"AI Won't Kill Junior Devs, But Your Process Might"* and *"Code Review in the +> Age of AI"*; the *DORA 2025* report; Addy Osmani / Zed, *"The 70% Problem."* Worth reading before +> Wednesday; cite carefully. + +--- + +## Part C — Verdict on the current design + prioritized refinements + +### C1. Scorecard: current design vs. the evidence + +| Design decision (current) | Evidence | Verdict | +|---|---|---| +| Predict before the reveal | Tucker 2024; pretesting effect | ✅ Strongly supported | +| Gated reveal (no prediction → no code) | Errorful-generation needs a *committed* attempt | ✅ Supported | +| Reveal + judge immediately after | Mera 2025 (immediate ≥ delayed) | ✅ Supported | +| Predict *judgment* (approach/data/flow/edges), not syntax | Generation benefit is for higher-order thinking | ✅ Supported | +| Friction only on Implementation tasks (Setup/Verification flow) | Task-complexity moderation (Akgun & Toker 2025) | ✅ Supported (could go finer) | +| Anti-sycophancy: always name a gap | Far transfer needs reflection on error | ✅ Supported | +| **Permanently-on gate** | **Expertise-reversal — must fade** | ❌ **Gap (P0)** | +| **All 4 dimensions on every Impl task** | **Generation reverses under overload** | ⚠️ **Risk (P1)** | +| **"Own" = acknowledge the gap** | **Self-explanation drives far transfer** | ⚠️ **Strengthen (P2)** | + +### C2. Prioritized refinements + +**P0 — Adaptive fading tied to the Prediction Scorecard.** +Use the per-dimension MATCH/PARTIAL/MISS history we already log. When a junior sustains high MATCH +rates on a dimension (e.g. 4–5 consecutive MATCHes on *data structure*), **fade the gate for that +dimension** — move from "predict all four" → "predict only the still-weak dimensions" → "free build +with spot-checks." Adaptive (by demonstrated score) beats a fixed schedule. This converts the +scorecard from a *vanity metric* into the *control signal* for the whole loop, and kills the +fatigue/rubber-stamping failure mode at its root. + +**P1 — Overload escape hatch on complex tasks.** +For tasks flagged high-complexity, **show a worked example or a partial scaffold first, then ask for a +prediction on the remaining decision** (a completion problem), instead of demanding a full four- +dimension prediction cold. Prevents the generation-effect reversal. + +**P2 — Self-explanation at the "Own" step + keep errors productive.** +Change the OWN step from "acknowledge the gap" to "**explain, in your words, *why* the actual approach +is better and where your prediction's logic broke**." Don't reward error-free predictions over honest +wrong ones — far transfer comes from reflecting on the error, not avoiding it. + +**P3 (nice-to-have) — Spaced re-prediction.** +Periodically re-surface a similar task and ask the junior to re-predict (retrieval + spacing). The +scorecard can detect a stale-but-weak dimension and schedule a re-rep. Addresses the literature's +weakest link (far transfer) without new infrastructure. + +### C3. Open questions worth saying out loud (to your boss) + +1. Does this transfer to *professional* juniors over weeks/months (not lab novices)? **Unproven — our + scorecard is the instrument that could eventually answer it.** +2. At what measured threshold should each dimension's gate fade? +3. How does the AI judge detect *rubber-stamping* (low-effort predictions submitted just to unlock the + reveal)? + +--- + +## Limitations (read before you cite this) + +- **Domain transfer:** strongest evidence = novice college students, short lab sessions, and + factual-recall tasks — *not* professional engineers predicting production code over time. Mechanism + is grounded **in principle**; longitudinal job transfer is plausible, not demonstrated. +- **Part B is artifact-based, not a controlled study** — real repo policies show the *norm*, not a + measured *effect*. +- **One preprint** in the set (Akgun & Toker 2025) is non-peer-reviewed (medium confidence). +- **The harness verified 25 of 114 extracted claims** (budget-bounded) — coverage is deep on the core + mechanism, lighter on the long tail. + +--- + +## Sources + +**Learning science (primary, claim-verified):** +- Tucker, Wang, Son & Stigler (2024), *Learning and Instruction* 91, 101871 — predict vs. produce (code). +- Akgun & Toker (2025), *"Struggle First, Prompt Later"* (preprint) — task-complexity moderation under GenAI. +- Richland, Kornell & Kao (2009), *JEP: Applied* — pretesting / errorful generation. +- *Memory & Cognition* (2025), s13421-025-01813-x — pretesting replication. +- Mera, Dianova & Marin-Garcia (2025), *Journal of Cognition* — feedback timing. +- Chen, Castro-Alonso, Paas & Sweller (2018), *Frontiers in Psychology* — generation reversal under load. +- Kalyuga (2007), *Educational Psychology Review* — expertise-reversal effect. +- Salden, Aleven, Schwonke & Renkl (2010), *Instructional Science* — adaptive fading. +- Renkl, Atkinson, Maier & Staley (2002) — backward-faded worked examples. + +**Industry practice (real repo artifacts, Octocode):** +- `Field-of-Dreams-Studio/hotaru` `readme.md`; `psimm/website` `ai.qmd`; `kornia/kornia-rs` + `AI_POLICY.md`; `github/docs` `copilot/responsible-use`; `xindoo/agentic-design-patterns` + Appendix G; `atomikos/transactions-essentials` `USING_AGENTS.md`; `vapor/vapor` `AGENTS.md`; + `ahochsteger/gmail-processor` `AGENTS.md`. + +**Practitioner (surfaced, not claim-verified):** Addy Osmani (substack, ×2); DORA 2025 report; Zed +*"The 70% Problem."* From 8e7464e5ed0c2de22868d513f0d77083229af51f Mon Sep 17 00:00:00 2001 From: Daniel Podolsky Date: Thu, 25 Jun 2026 11:55:32 +0300 Subject: [PATCH 3/6] feat(junior-profile): add adaptive fading to the predict-before-reveal gate MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Implements the P0 refinement the research identified: the prediction gate must relax as competence grows (expertise-reversal effect), or it decays into a tax → fatigue → rubber-stamping. The gate now fades PER-DIMENSION, driven by the data we already log (Prediction Scorecard) — turning that metric from a vanity readout into the loop's control signal. - profiles/junior.md: new "Adaptive Fading" rule — cautious thresholds (4 consecutive MATCHes fades a dimension to spot-check; PARTIAL/MISS resets streak; MISS on a re-asked faded dimension snaps it back). Ownership floor never removed. - own/feature.md: Phase 6 reads the scorecard up front, computes per-dimension fade state, and gates only the still-weak dimensions; faded ones get a spot-check. Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_013ghhtyQRy5nmSGBbCaNpwH --- .claude/commands/own/feature.md | 25 ++++++++++++++++++------- profiles/junior.md | 31 ++++++++++++++++++++++++++++++- 2 files changed, 48 insertions(+), 8 deletions(-) diff --git a/.claude/commands/own/feature.md b/.claude/commands/own/feature.md index f07ed0d..b74cd56 100644 --- a/.claude/commands/own/feature.md +++ b/.claude/commands/own/feature.md @@ -357,18 +357,29 @@ mechanism. Because `/own:feature` runs Phase 6 inline, the gate can't be bypasse 1. **Read the tasks** just written to the phase's `tasks[]`. Identify the `Implementation`-group tasks (these gate) vs. `Setup` / `Verification` (these flow). +1b. **Read the Prediction Scorecard** in `~/ownyourcode/learning/LEARNING_REGISTRY.md` + and compute each dimension's **fade state** (see `junior.md` → "Adaptive Fading"): + count consecutive trailing `MATCH`es per dimension (approach / data structure / + control flow / edge cases). A dimension with **≥4 consecutive MATCHes is Faded**; + otherwise it is **Gated**. If the file/section is missing, treat all dimensions as + Gated (default). This decides which dimensions each task will actually ask for. + 2. **For each task, in order:** - **Setup / Verification task** → implement it directly, no prediction gate. (Scaffolding and test-running carry no design judgment.) - - **Implementation task** → run the full gate: - 1. **PREDICT** — present the prediction prompt (4 dimensions, free-text, - N/A-with-reason allowed). Do not proceed until answered with specifics; - bounce vague answers. + - **Implementation task** → run the gate **on the still-Gated dimensions only**: + 1. **PREDICT** — present the prediction prompt for **only the Gated dimensions** + (free-text, N/A-with-reason allowed). Faded dimensions are NOT asked. Do not + proceed until the Gated ones are answered with specifics; bounce vague answers. + (If ALL four are Faded, treat the task like Setup: build + spot-check, no gate.) 2. **GATE** — no committed prediction → no code. Don't cave to "just show me." 3. **REVEAL** — write the actual production code for that task. - 4. **JUDGE** — grade prediction vs. actual on the rubric (MATCH/PARTIAL/MISS - per relevant dimension), name the specific gap, ground it (Context7 for - authority, Octocode for prevalence — cite *why*, not just *that it's common*). + 4. **JUDGE** — grade the **predicted (Gated)** dimensions on the rubric + (MATCH/PARTIAL/MISS), name the specific gap, ground it (Context7 for authority, + Octocode for prevalence — cite *why*, not just *that it's common*). For **Faded** + dimensions, do a lightweight **spot-check**: state what you did and flag if they'd + likely have missed it — but don't grade it unless you re-asked it as a snap-back + check on a complex task (a `MISS` there returns that dimension to Gated). 5. **OWN** — have them acknowledge the named gap in their own words. 3. **Record** each Implementation task's verdicts to the **Prediction Scorecard** in diff --git a/profiles/junior.md b/profiles/junior.md index 028a714..dd4d7c9 100644 --- a/profiles/junior.md +++ b/profiles/junior.md @@ -162,7 +162,36 @@ Append each task's per-dimension verdicts to the **Prediction Scorecard** in `~/ownyourcode/learning/LEARNING_REGISTRY.md`. Every `MISS` also becomes a row in that file's **Failures (Anti-Patterns)** table. Over time this shows the judgment curve (e.g. edge-case MATCH rate rising) — the proof the gym works. -``` + +### Adaptive Fading (the gate relaxes as the junior proves the skill) + +> Grounded in the **expertise-reversal effect**: scaffolding that helps a novice +> *harms* a learner who has outgrown it (it becomes a tax → fatigue → rubber-stamping). +> So the gate must FADE per-dimension, driven by demonstrated competence — not stay +> on forever. The Prediction Scorecard is the signal that drives the fade. +> (See `docs/research/junior-profile-predict-before-reveal-validation.md`.) + +**The fade is PER-DIMENSION** (approach / data structure / control flow / edge cases), +not per-task. A junior can be fluent on data structure while still weak on edge cases. + +**Cautious thresholds (v1 — slow to trust, quick to re-engage):** + +| State | How a dimension reaches it | What happens at prediction time | +|-------|----------------------------|---------------------------------| +| 🟢 **Gated** (default) | new dimension, or snapped back | junior MUST predict this dimension | +| ⚪ **Faded** | **4 consecutive `MATCH`es** on that dimension | junior is NOT asked to predict it; at reveal the AI **spot-checks** it — states what it did and flags if they'd likely have missed something | + +**Counter rules:** +- Only a `MATCH` advances a dimension's streak. A `PARTIAL` or `MISS` **resets the + streak to 0** (it does not, by itself, fade anything). +- **Snap-back:** on a notably complex/high-stakes task, re-ask a *faded* dimension as a + check. A `MISS` there snaps it back to 🟢 Gated (streak 0). The junior may also opt to + predict a faded dimension anytime. +- A task therefore asks for **only the still-Gated dimensions** — this is the natural + "partial gate." If all four have faded, the task flows like Setup (build + spot-check). + +**Never fully remove the floor:** even when all dimensions are faded, keep the +spot-check and `/own:done` Gate 1 — fading reduces friction, it does not remove ownership. --- From 9fd7be25448dd9f5ea8bb32156bf8e0f0023276c Mon Sep 17 00:00:00 2001 From: Daniel Podolsky Date: Sat, 27 Jun 2026 18:03:16 +0300 Subject: [PATCH 4/6] =?UTF-8?q?fix(junior-profile):=20address=20PR=20revie?= =?UTF-8?q?w=20=E2=80=94=20implement=20P2,=20deterministic=20snap-back,=20?= =?UTF-8?q?phased-rollout=20copy?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Resolves the three actionable review comments on PR #21: - P2 (ownership-critical): OWN step changed from "acknowledge the gap" to "explain WHY the actual approach is better and WHERE your prediction's logic broke" — self-explanation, not recognition. Removes the contradiction between the shipped research doc (which recommended P2) and the implementation. Applied in both junior.md and feature.md Phase 6. - Adaptive fading: documented that the "4 consecutive MATCHes" threshold is a deliberately conservative v1 number (research lists it as open), and added a DETERMINISTIC staleness nudge (re-ask a faded dimension after 5 stale tasks) so snap-back no longer depends solely on a soft judgment trigger — a lightweight form of the research's P3 spaced-re-prediction. - Phased-rollout copy: "Other profiles don't need the gym" reframed as deliberate v1 scoping, naming Interview Prep + Career Switcher as the intended next profiles rather than a permanent exclusion. - Research doc: annotated implementation status (P0 ✅, P2 ✅, P3 ⚙️ partial, P1 ⏳). Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_013ghhtyQRy5nmSGBbCaNpwH --- .claude/commands/own/feature.md | 30 ++++++++++++++----- ...rofile-predict-before-reveal-validation.md | 5 ++++ profiles/junior.md | 27 +++++++++++++---- 3 files changed, 48 insertions(+), 14 deletions(-) diff --git a/.claude/commands/own/feature.md b/.claude/commands/own/feature.md index b74cd56..7fde616 100644 --- a/.claude/commands/own/feature.md +++ b/.claude/commands/own/feature.md @@ -45,8 +45,13 @@ junior a finished feature to read. **How "build" works depends on profile:** - **Junior profile** → Phase 6 runs the Implementation Loop: the junior predicts the judgment for each task *before* the AI reveals the code, then gets graded on the prediction. They own the code by being able to evaluate it, not by transcribing it. -- **Other profiles** → SDD stops at the spec; implementation happens however that - developer ships (they don't need the gym). +- **Other profiles (v1)** → the loop is **not yet wired** for them; SDD stops at the spec + and implementation happens however that developer ships. + > **Deliberate v1 scoping, not a permanent exclusion.** The loop is built for the Junior + > profile first. **Interview Prep** is the strongest candidate to get it next — defending + > judgment in a live review is exactly what predict-before-reveal trains — with **Career + > Switcher** (rebuilding fundamentals) close behind. A future PR can extend Phase 6 to + > those profiles without contradicting this copy. --- @@ -339,9 +344,10 @@ Based on response: **⚠️ Profile Check:** Read `.claude/ownyourcode-manifest.json`. - If `profile.type = "junior"` → run this phase. The command builds the feature task-by-task through Predict → Reveal → Judge. -- All other profiles → **skip Phase 6.** End the command after Phase 5 with the - usual "now implement" handoff. (This phase is the junior gym; seniors ship in - the game.) +- All other profiles → **skip Phase 6 (v1).** End the command after Phase 5 with the + usual "now implement" handoff. The loop is wired for Junior first by deliberate v1 + scoping — **Interview Prep** and **Career Switcher** are the intended next profiles, + not permanent exclusions (see "The SDD Philosophy" above). > **Authority:** the full loop mechanics, prediction prompt, rubric, grounding > guard, and anti-sycophancy rule live in `profiles/junior.md` → "The Implementation @@ -363,6 +369,10 @@ mechanism. Because `/own:feature` runs Phase 6 inline, the gate can't be bypasse control flow / edge cases). A dimension with **≥4 consecutive MATCHes is Faded**; otherwise it is **Gated**. If the file/section is missing, treat all dimensions as Gated (default). This decides which dimensions each task will actually ask for. + Also compute **staleness** per Faded dimension: how many logged tasks since it was + last graded. A Faded dimension that is **≥5 tasks stale** is re-asked once this phase + (the deterministic staleness nudge) — a `MISS` snaps it back to Gated, a `MATCH` + resets its staleness. 2. **For each task, in order:** - **Setup / Verification task** → implement it directly, no prediction gate. @@ -378,9 +388,13 @@ mechanism. Because `/own:feature` runs Phase 6 inline, the gate can't be bypasse (MATCH/PARTIAL/MISS), name the specific gap, ground it (Context7 for authority, Octocode for prevalence — cite *why*, not just *that it's common*). For **Faded** dimensions, do a lightweight **spot-check**: state what you did and flag if they'd - likely have missed it — but don't grade it unless you re-asked it as a snap-back - check on a complex task (a `MISS` there returns that dimension to Gated). - 5. **OWN** — have them acknowledge the named gap in their own words. + likely have missed it. Snap-back to Gated happens on a `MISS` when a faded + dimension was re-asked — either by the **deterministic staleness nudge** (step 1b) + or because this was a notably complex/high-stakes task. + 5. **OWN** — have them **explain *why* the actual approach is better and *where their + prediction's logic broke***, not just acknowledge the gap (the self-explanation + step — see `junior.md` → OWN). Push past a vague "yeah I missed that" to the causal + *why*; that reconstruction is the ownership evidence `/own:done` Gate 1 consumes. 3. **Record** each Implementation task's verdicts to the **Prediction Scorecard** in `~/ownyourcode/learning/LEARNING_REGISTRY.md`, and add every `MISS` to that file's diff --git a/docs/research/junior-profile-predict-before-reveal-validation.md b/docs/research/junior-profile-predict-before-reveal-validation.md index 4acdf16..2d14104 100644 --- a/docs/research/junior-profile-predict-before-reveal-validation.md +++ b/docs/research/junior-profile-predict-before-reveal-validation.md @@ -208,6 +208,11 @@ just inside a learning tool. ### C2. Prioritized refinements +> **Implementation status (updated post-review, PR #21):** **P0 ✅ shipped**; +> **P2 ✅ shipped** (OWN step is now a self-explanation, not an acknowledgement); +> **P3 ⚙️ partial** — a deterministic *staleness nudge* re-asks a faded dimension after +> 5 stale tasks (lightweight spaced re-prediction). **P1 ⏳ not yet built.** + **P0 — Adaptive fading tied to the Prediction Scorecard.** Use the per-dimension MATCH/PARTIAL/MISS history we already log. When a junior sustains high MATCH rates on a dimension (e.g. 4–5 consecutive MATCHes on *data structure*), **fade the gate for that diff --git a/profiles/junior.md b/profiles/junior.md index dd4d7c9..cd00646 100644 --- a/profiles/junior.md +++ b/profiles/junior.md @@ -153,9 +153,14 @@ must come **before** the reveal, and why being wrong is productive, not a failur use Octocode for prevalence. If you can't justify *why*, say so rather than citing frequency as if it were proof. -5. **OWN** — The junior acknowledges the named gap in their own words before moving - on. Then record the scores (see Measurement below). This transcript becomes the - evidence for `/own:done` Gate 1 (Ownership). +5. **OWN** — The junior must **explain, in their own words, *why* the actual approach is + better and *where their prediction's logic broke*** — not merely acknowledge that a + gap exists. Acknowledgement is recognition; reconstruction is ownership. (This is the + **self-explanation** step: far transfer comes from reasoning about the error, not from + noting it — see research doc §C2 P2.) A vague "yeah I missed that" doesn't close the + step; push for the causal *why*, same as the prediction's "be specific" bar. Then record + the scores (see Measurement below). This reconstruction is the evidence `/own:done` + Gate 1 (Ownership) consumes. **Measurement (Protocol E — the eval is built in):** Append each task's per-dimension verdicts to the **Prediction Scorecard** in @@ -181,12 +186,22 @@ not per-task. A junior can be fluent on data structure while still weak on edge | 🟢 **Gated** (default) | new dimension, or snapped back | junior MUST predict this dimension | | ⚪ **Faded** | **4 consecutive `MATCH`es** on that dimension | junior is NOT asked to predict it; at reveal the AI **spot-checks** it — states what it did and flags if they'd likely have missed something | +> **The "4" is a deliberately conservative v1 number, not a settled one.** The research +> lists "at what threshold should each dimension fade?" as an *open question* (§C3 Q2). +> Treat it as a starting dial to tune against real scorecard data, not a constant. + **Counter rules:** - Only a `MATCH` advances a dimension's streak. A `PARTIAL` or `MISS` **resets the streak to 0** (it does not, by itself, fade anything). -- **Snap-back:** on a notably complex/high-stakes task, re-ask a *faded* dimension as a - check. A `MISS` there snaps it back to 🟢 Gated (streak 0). The junior may also opt to - predict a faded dimension anytime. +- **Snap-back has two triggers — one deterministic, one judgment-based:** + - *Deterministic staleness nudge (primary):* a faded dimension that has **gone 5 tasks + without being re-checked** is automatically re-asked once (a one-off "prove it's still + there"). A `MISS` snaps it back to 🟢 Gated; a `MATCH` re-arms the staleness counter. + This makes re-engagement scorecard-driven, not vibes — it is the lightweight form of + the research's P3 "spaced re-prediction" (§C3). + - *Judgment-based (secondary):* on a notably complex/high-stakes task, re-ask a faded + dimension regardless of staleness; a `MISS` snaps it back. The junior may also opt to + predict a faded dimension anytime. - A task therefore asks for **only the still-Gated dimensions** — this is the natural "partial gate." If all four have faded, the task flows like Setup (build + spot-check). From 8e4e4b3e9c645b4eb3bf404598c5b56426fa9f9f Mon Sep 17 00:00:00 2001 From: Daniel Podolsky Date: Sat, 27 Jun 2026 18:09:50 +0300 Subject: [PATCH 5/6] =?UTF-8?q?docs(release):=20cut=202.7.0=20=E2=80=94=20?= =?UTF-8?q?changelog,=20README=20sync,=20version=20bump=20(resolves=20revi?= =?UTF-8?q?ew=20D1/D2)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Addresses the two required items the gatekeeper held on: - D2: add the 2.7.0 CHANGELOG entry (MINOR — predict-before-reveal Junior loop, Phase 6 gate, Prediction Scorecard, adaptive fading, self-explanation OWN step). - D1: README Commands table now states the Junior gym runs inline in /own:feature Phase 6 and that /own:guide is no longer the primary implementation path. - Bumped version strings 2.6.0 -> 2.7.0 across installers, README badge, and the dashboard-data template so the release is internally consistent (.ps1 stays pure ASCII). The DASHBOARD_CONTRACT example value is illustrative and left as-is. Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_013ghhtyQRy5nmSGBbCaNpwH --- CHANGELOG.md | 10 ++++++++++ README.md | 8 +++++--- core/templates/dashboard-data.js.template | 2 +- scripts/base-install.ps1 | 4 ++-- scripts/base-install.sh | 4 ++-- scripts/project-install.ps1 | 10 +++++----- scripts/project-install.sh | 10 +++++----- 7 files changed, 30 insertions(+), 18 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 1e09241..4ec7a2e 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,15 @@ # Changelog +## 2.7.0 + +- Reworked the Junior profile from "hand-type every line" to **predict-before-reveal**: on each implementation task the junior commits a prediction (approach, data structure, control flow, edge cases) *before* the AI writes the code, then the AI grades the prediction against a rubric and names the specific gap — ownership shifts from typing the code to being able to evaluate it +- The predict-before-reveal loop runs inline as a new `/own:feature` **Phase 6** (Junior profile only) so the gate can't be skipped; only judgment-carrying Implementation tasks gate, while Setup and Verification tasks flow +- Added a per-dimension **Prediction Scorecard** to the global learning registry that logs MATCH/PARTIAL/MISS over time, turning "is the junior's judgment improving?" into a measurable curve +- Added **adaptive fading**: the prediction gate relaxes per-dimension as the junior proves the skill (4 consecutive matches retires a dimension to a spot-check), with a deterministic staleness re-check so a faded-but-rusty dimension re-engages on its own — the gym never decays into a rubber-stamp tax +- The Junior `OWN` step now requires a self-explanation (why the actual approach is better and where the prediction broke), feeding `/own:done` Gate 1 with real ownership evidence +- Added `docs/research/junior-profile-predict-before-reveal-validation.md` — the redesign validated against learning-science literature and real-world industry practice, with prioritized refinements +- `/own:guide` is no longer the primary implementation path for juniors; it remains available for ad-hoc help (README and command docs updated to match) + ## 2.6.0 - Added a boot sequence — a terminal window types your live project status (phases, task counts) on load; any key skips it, `prefers-reduced-motion` bypasses it, `#noboot` disables it diff --git a/README.md b/README.md index d14afde..8ad6f9c 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@

- v2.6.0 · MIT License + v2.7.0 · MIT License

--- @@ -102,13 +102,15 @@ Learnings compound across projects. Patterns that worked. Mistakes you won't rep | Command | Purpose | | -------------- | ---------------------------------- | | `/own:init` | Set your profile, stack, and goals | -| `/own:feature` | Plan with spec-driven development | +| `/own:feature` | Plan with spec-driven development — and, for the Junior profile, build it via the predict-before-reveal loop (Phase 6) | | `/own:advise` | Query past learnings before starting | -| `/own:guide` | Get implementation guidance | +| `/own:guide` | Optional implementation help (for the Junior profile the gym now runs inline in `/own:feature` Phase 6) | | `/own:stuck` | Debug systematically | | `/own:done` | Complete with gates + code review | | `/own:retro` | Capture learnings | +> **Junior profile note:** implementation for juniors happens inside `/own:feature` (Phase 6) as a *predict-before-reveal* loop — you commit a prediction before the AI reveals code, then get graded on it. `/own:guide` remains available for ad-hoc help but is no longer the primary path to writing code. + ### Utilities | Command | Purpose | diff --git a/core/templates/dashboard-data.js.template b/core/templates/dashboard-data.js.template index 0070fba..dd05f38 100644 --- a/core/templates/dashboard-data.js.template +++ b/core/templates/dashboard-data.js.template @@ -25,7 +25,7 @@ window.PROJECT = { audience: "myself", mission: "This dashboard is empty. Run /own:init in Claude Code to define your project's mission, stack, and roadmap — then /own:feature to spec your first phase.", generated: "—", - version: "2.6.0", + version: "2.7.0", }, dod: [], // Definition-of-Done items: { text, done } stack: [], // 5-tuple rows: [layer, tech, version, source, purpose] diff --git a/scripts/base-install.ps1 b/scripts/base-install.ps1 index 1d29960..29ec446 100644 --- a/scripts/base-install.ps1 +++ b/scripts/base-install.ps1 @@ -1,6 +1,6 @@ # OwnYourCode Base Installation Script (Windows) # AI-Mentored Development for All Developers -# Version 2.6.0 - Dashboard Elevated +# Version 2.7.0 - Dashboard Elevated # # Usage: irm https://raw.githubusercontent.com/DanielPodolsky/ownyourcode/main/scripts/base-install.ps1 | iex @@ -20,7 +20,7 @@ function Write-Err { param($msg) Write-Host "[ERROR] $msg" -ForegroundColor Red; # Header Write-Host "" Write-Host "+=======================================================+" -ForegroundColor Green -Write-Host "| OwnYourCode Installation v2.6.0 |" -ForegroundColor Green +Write-Host "| OwnYourCode Installation v2.7.0 |" -ForegroundColor Green Write-Host "| AI-Mentored Development with Profile Support |" -ForegroundColor Green Write-Host "+=======================================================+" -ForegroundColor Green Write-Host "" diff --git a/scripts/base-install.sh b/scripts/base-install.sh index e99666d..ad06040 100755 --- a/scripts/base-install.sh +++ b/scripts/base-install.sh @@ -2,7 +2,7 @@ # OwnYourCode Base Installation Script # AI-Mentored Development for All Developers -# Version 2.6.0 - Dashboard Elevated +# Version 2.7.0 - Dashboard Elevated # # Usage: curl -sSL https://raw.githubusercontent.com/DanielPodolsky/ownyourcode/main/scripts/base-install.sh | bash @@ -28,7 +28,7 @@ error() { echo -e "${RED}[ERROR]${NC} $1"; exit 1; } # Header echo "" echo -e "${GREEN}╔═══════════════════════════════════════════════════════╗${NC}" -echo -e "${GREEN}║ OwnYourCode Installation v2.6.0 ║${NC}" +echo -e "${GREEN}║ OwnYourCode Installation v2.7.0 ║${NC}" echo -e "${GREEN}║ AI-Mentored Development with Profile Support ║${NC}" echo -e "${GREEN}╚═══════════════════════════════════════════════════════╝${NC}" echo "" diff --git a/scripts/project-install.ps1 b/scripts/project-install.ps1 index c7bd4b3..3d8d964 100644 --- a/scripts/project-install.ps1 +++ b/scripts/project-install.ps1 @@ -1,6 +1,6 @@ # OwnYourCode Project Installation Script (Windows) # AI-Mentored Development for All Developers -# Version 2.6.0 - Dashboard Elevated +# Version 2.7.0 - Dashboard Elevated $ErrorActionPreference = "Stop" @@ -18,7 +18,7 @@ function Write-Err { param($msg) Write-Host "[ERROR] $msg" -ForegroundColor Red; # Header Write-Host "" Write-Host "+===========================================================+" -ForegroundColor Green -Write-Host "| OwnYourCode Installation v2.6.0 |" -ForegroundColor Green +Write-Host "| OwnYourCode Installation v2.7.0 |" -ForegroundColor Green Write-Host "| AI-Mentored Development with Profile Support |" -ForegroundColor Green Write-Host "+===========================================================+" -ForegroundColor Green Write-Host "" @@ -367,7 +367,7 @@ $timestamp = (Get-Date).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ") $manifestContent = @" { - "version": "2.6.0", + "version": "2.7.0", "installed_at": "$timestamp", "claude_md_location": "$CLAUDE_MD_REL", "backup_path": $backupJson, @@ -442,11 +442,11 @@ Write-OK "Manifest created at .claude/ownyourcode-manifest.json" Write-Host "" Write-Host "+===========================================================+" -ForegroundColor Green -Write-Host "| Installation Complete! v2.6.0 |" -ForegroundColor Green +Write-Host "| Installation Complete! v2.7.0 |" -ForegroundColor Green Write-Host "+===========================================================+" -ForegroundColor Green Write-Host "" -Write-OK "OwnYourCode v2.6.0 installed successfully!" +Write-OK "OwnYourCode v2.7.0 installed successfully!" Write-Host "" Write-Info "What was created:" diff --git a/scripts/project-install.sh b/scripts/project-install.sh index c361ac3..495b90d 100755 --- a/scripts/project-install.sh +++ b/scripts/project-install.sh @@ -2,7 +2,7 @@ # OwnYourCode Project Installation Script # AI-Mentored Development for All Developers -# Version 2.6.0 - Dashboard Elevated +# Version 2.7.0 - Dashboard Elevated set -e @@ -29,7 +29,7 @@ error() { echo -e "${RED}[ERROR]${NC} $1"; exit 1; } # Header echo "" echo -e "${GREEN}╔═══════════════════════════════════════════════════════════╗${NC}" -echo -e "${GREEN}║ OwnYourCode Installation v2.6.0 ║${NC}" +echo -e "${GREEN}║ OwnYourCode Installation v2.7.0 ║${NC}" echo -e "${GREEN}║ AI-Mentored Development with Profile Support ║${NC}" echo -e "${GREEN}╚═══════════════════════════════════════════════════════════╝${NC}" echo "" @@ -325,7 +325,7 @@ fi cat > "$MANIFEST" << EOF { - "version": "2.6.0", + "version": "2.7.0", "installed_at": "$(date -u +%Y-%m-%dT%H:%M:%SZ)", "claude_md_location": "$CLAUDE_MD_REL", "backup_path": $BACKUP_JSON, @@ -399,11 +399,11 @@ success "Manifest created at .claude/ownyourcode-manifest.json" echo "" echo -e "${GREEN}╔═══════════════════════════════════════════════════════════╗${NC}" -echo -e "${GREEN}║ Installation Complete! v2.6.0 ║${NC}" +echo -e "${GREEN}║ Installation Complete! v2.7.0 ║${NC}" echo -e "${GREEN}╚═══════════════════════════════════════════════════════════╝${NC}" echo "" -success "OwnYourCode v2.6.0 installed successfully!" +success "OwnYourCode v2.7.0 installed successfully!" echo "" info "What was created:" From de685493b9cf9663f8e903ec7d7ad6c6a2440544 Mon Sep 17 00:00:00 2001 From: Daniel Podolsky Date: Sat, 27 Jun 2026 18:13:29 +0300 Subject: [PATCH 6/6] chore(core): finish 2.7.0 version sweep in /own:init manifest writes Completes the version bump the gatekeeper flagged as incomplete: /own:init still wrote 2.6.0 into the manifest and dashboard meta (L618, L642, L1224) and the field-mapping contract (L1257), so a freshly-initialized project would land a 2.6.0 manifest under a 2.7.0 release. All four now write 2.7.0, consistent with the installers and templates. (Uses a valid commit scope per the D3 nit.) Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_013ghhtyQRy5nmSGBbCaNpwH --- .claude/commands/own/init.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/.claude/commands/own/init.md b/.claude/commands/own/init.md index 8c9de58..bd1530f 100644 --- a/.claude/commands/own/init.md +++ b/.claude/commands/own/init.md @@ -615,7 +615,7 @@ Update `.claude/ownyourcode-manifest.json` with profile settings: ```json { - "version": "2.6.0", + "version": "2.7.0", "installed_at": "...", "profile": { "type": "junior", @@ -639,7 +639,7 @@ Update `.claude/ownyourcode-manifest.json` with profile settings: ```json { - "version": "2.6.0", + "version": "2.7.0", "installed_at": "...", "profile": { "type": "custom", @@ -1221,7 +1221,7 @@ window.PROJECT = { audience: "[enum: myself | employers | clients | real-users]", mission: "[the PROBLEM statement, in the user's words]", generated:"[today YYYY-MM-DD]", - version: "2.6.0", + version: "2.7.0", }, dod: [ { text: "[one concrete, measurable done-criterion]", done: false }, @@ -1254,7 +1254,7 @@ window.PROJECT = { | `meta.audience` | Phase 3 selection → enum: "Yourself"→`myself`, "Employers"→`employers`, "A client"→`clients`, "Real users"→`real-users` | | `meta.mission` | Phase 2 problem statement (the *why*, in their words) | | `meta.generated` | Today, `YYYY-MM-DD` | -| `meta.version` | Literal `2.6.0` | +| `meta.version` | Literal `2.7.0` | | `dod[]` | Phase 4 Definition-of-Done items, each `done:false` | | `stack[]` | Phase 5 stack + Phase 5.1 MCP-verified versions, as 5-tuples | | `phases[]` | Phase 5.5 collaborative roadmap — each `status:"roadmap-only"` with `items:[…]`, NO `spec`/`design`/`tasks` (those come from `/own:feature`) |