yam-flow 2.0.0 → 2.1.0

package/AGENTS.md

@@ -8,14 +8,15 @@
 6. Check local project fit before changing code, even for small work.
 7. Prefer existing project patterns over new abstractions.
 8. Make the smallest useful change.
-9. Verify at the lightest level that honestly supports the claim, then escalate verification when the claim is larger.
+9. Verify at the lightest level that honestly supports the claim, then escalate verification with the L0-L5 Verification Ladder when the claim, scope, risk, public release, runtime, UI completion, auth, DB, broad refactor, learning value, or user intent is larger.
 10. Report skipped, partial, blocked, or assumed verification plainly.
 11. Do not run broad tests for tiny changes, but do not under-verify risky, security-sensitive, or public work.
 12. Do not use teams, orchestration, structured proof, or tmux unless risk, user intent, learning value, or an approved route justifies it.
 13. Escalate risky work by asking or recommending, not by silently switching modes.
 14. For UI work, inspect real states and responsive behavior when feasible.
 15. For long-running processes, do not claim cleanup unless process exit is checked.
-16. Explain useful change insight for non-specialists: what the touched code does, what changed, and why it matters.
-17. Use external references deliberately, preserve source clarity in research/proof notes, and rework good ideas into yam style.
-18. Treat security as the first project lens: identify sensitive surfaces early and guide safer defaults before convenience.
-19. Keep final reports short and concrete, but always include remaining tasks or state that none are meaningful.
+16. When code, config, release metadata, documentation, or project artifacts changed, include a Study Note even if no yam skill was explicitly invoked.
+17. Explain useful change insight for non-specialists: what the touched code or artifact does, what role it has, what was wrong or missing, what changed, what behavior is expected, one useful syntax/structure insight, what was verified, and what remains uncertain.
+18. Use external references deliberately, preserve source clarity in research/proof notes, and rework good ideas into yam style.
+19. Treat security as the first project lens: identify sensitive surfaces early and guide safer defaults before convenience.
+20. Keep final reports short and concrete, but always include remaining tasks or state that none are meaningful.

package/CHANGELOG.md

@@ -2,6 +2,18 @@
 
 All notable changes to yam-flow are documented here.
 
+## v2.1.0 - 2026-06-30
+
+### Added
+
+- Added `references/study-note.md` with required Study Note guidance for any changed code, config, release metadata, documentation, or project artifact.
+- Reworked `references/verification-levels.md` into an L0-L5 Verification Ladder covering stated, inspected, local check, integrated, release/runtime/visual proof, and bounded deep verification.
+
+### Improved
+
+- Updated core, final-report, route skill, project-pack, and trust-layer guidance so serious claims can require heavier evidence while bounded stop conditions prevent endless proof loops.
+- Strengthened `$quick`, `$deep`, `$mission`, and `$ueye` final report rules so changed artifacts include code/artifact role, expected behavior, syntax or structure insight, verification note, and uncertainty.
+
 ## v2.0.0 - 2026-06-24
 
 ### Added

package/COMMANDS.md

@@ -195,8 +195,9 @@ Supported report shapes:
 
 - Runtime evidence mini: command/process, observation, cleanup, truth status, next action.
 - Patch queue lite: mission lane status, changed files, verification hint, rollback hint, truth status.
+- Verification Ladder: L0 stated, L1 inspected, L2 local check, L3 integrated, L4 release/runtime/visual proof, L5 bounded deep with stop condition and skipped/remaining work.
 - Loop report: intent, guided stage outcomes, evidence level/stamp, blockers, blocker kind, safe retry, next action, fix-first items, remaining tasks, recommended direction, blocked-by notes, owner route/scope, side effects, and study note.
-- Study note: short non-specialist explanation of the failing code, its role, observed symptom, changed code, and why it matters.
+- Study note: short non-specialist explanation of the changed code/artifact, its role, what was wrong or missing, expected behavior, one syntax/structure insight, verification, and uncertainty.
 - Benchmark optimization loop lite: baseline, one change, rerun, keep/revert decision.
 - Structured diagnostic next action: severity, evidence, owner route, next action, truth status.
 - Ueye continuity/comparison: previous report, current report, comparison delta, design quality, next action.

package/DECISIONS.md

@@ -38,11 +38,14 @@ Every `yam` change is evaluated against honest proof, progressive depth, securit
 - Rules the model can actually follow.
 - Fast momentum without pretending simple work is always enough.
 - Depth growth when the user's understanding, project risk, or product quality benefits from it.
+- L0-L5 verification ladder with bounded heavy verification and explicit stop conditions.
 
 ### Beginner Insight
 
 - Explain changed behavior in plain language.
 - Name the code area touched and what it is responsible for.
+- Include Study Note whenever code, config, release metadata, documentation, or project artifacts changed.
+- Teach one useful syntax, schema, or structure insight without turning the final report into a long tutorial.
 - Separate implementation facts from judgment.
 - Always close with remaining tasks or useful improvements.
 

package/README.md

@@ -14,6 +14,8 @@ Context-reuse first.
 End with remaining tasks and fix-first items.
 Security-first project guidance.
 Useful change insight for non-specialists.
+Study Note for changed artifacts.
+Verification Ladder for larger claims.
 Reference-led judgment with clear source boundaries.
 ```
 
@@ -31,17 +33,18 @@ See `ROADMAP.md` for remaining implementation stages.
 
 ## Defaults
 
-- No hooks.
+- No required hooks.
 - Optional `yam-lite` hook is advisory-only and off by default.
 - No automatic Team routing.
 - No automatic proof loops.
 - No automatic tmux.
 - No false completion claims: verification, cleanup, and visual checks must match actual evidence.
 - `yam` is not lightweight-only; it is progressive: fast direction, broader judgment when useful, stronger proof as scope/risk grows.
-- Every route should check project direction and use an honest verification level.
+- Every route should check project direction and use the L0-L5 Verification Ladder honestly.
 - Small work stays small, but serious work is allowed to become serious.
 - Security-sensitive work is never treated as ordinary polish.
-- Useful reports explain what the changed code does, how it changed, and why the change matters.
+- When code, config, release metadata, documentation, or project artifacts changed, final reports include a Study Note even if no yam skill was invoked.
+- Useful Study Notes explain what the changed code or artifact does, what role it has, what was wrong or missing, what changed, what behavior is expected, one small syntax/structure insight, what was verified, and what remains uncertain.
 - Research and reference scans should keep source boundaries clear, then rework good ideas into yam style.
 - Token economy is part of quality.
 - Project packs prevent re-reading and re-planning from scratch.
@@ -215,9 +218,10 @@ These shapes keep reports machine-readable without turning normal work into a he
 
 - Runtime evidence mini: compact route, command/process, observation, cleanup, truth status, and next action fields for `$deep` or `$mission` runtime claims.
 - Patch queue lite: `$mission` lane records with pending/applied/verified/reverted/blocked state, changed files, verification hint, rollback hint, truth status, and next action.
+- Verification Ladder: L0 stated, L1 inspected, L2 local check, L3 integrated, L4 release/runtime/visual proof, and L5 bounded deep. Heavier claims require heavier evidence, but stop conditions prevent endless proof loops.
 - Release report JSON: `yam release report --json` summarizes typecheck, forbidden-name scan, package boundary, registry status, CLI smoke, dist freshness, diagnostics, readiness receipt, and final truth status.
 - Loop report JSON: `yam loop report --json` records a read-only handoff artifact: guided stages, requirement coverage, evidence level/stamp, blocker kind, failure cause, safe retry, recovery hint, owner route/scope, side effects, next action, fix-first items, remaining tasks, recommended direction, implementation notes, blocked-by notes, avoidance note, tool intent, truth status, and study note.
-- Study note: `yam.study-note.v1` keeps short non-specialist explanations for what code was failing, what role it plays, how the symptom showed up, what changed, and why it matters. Missing details stay in `limits` instead of being guessed.
+- Study note: `yam.study-note.v1` and `references/study-note.md` keep non-specialist explanations for what code/artifact changed, what role it plays, what was wrong or missing, what behavior is expected, one syntax/structure insight, what was verified, and what remains uncertain. Missing details stay in `limits` instead of being guessed.
 - Avoidance note: loop reports may include one short mistake-to-avoid note, but durable memory stays explicit through `yam memory add`; `yam loop report` does not write `.yam/memory`.
 - Publish blocker evidence: release reports classify common npm auth, permission, OTP, immutable-version, cache, registry, and tarball failures into safe next actions.
 - Publish readiness evidence: release reports run read-only registry/auth/version probes, redact account/token details, keep npm publish outside the report, and include a `yam.release-readiness-receipt.v1` basis for the readiness judgment.

package/dist/bin/yam.js

@@ -318,6 +318,7 @@ async function verify({ quiet = false } = {}) {
         'token-economy.md',
         'context-reuse.md',
         'markdown-management.md',
+        'study-note.md',
         'final-report.md',
         'token-budget-reporter.md',
         'memory.md'
@@ -3782,7 +3783,7 @@ function printDetection(result) {
     }
     console.log('');
     console.log('Smallest useful checks:');
-    console.log(`- $quick: ${result.commands.typecheck || result.commands.lint || result.commands.test || result.commands.build || 'Level 0 read/inspect; no command detected'}`);
+    console.log(`- $quick: ${result.commands.typecheck || result.commands.lint || result.commands.test || result.commands.build || 'L1 inspected; no command detected'}`);
     console.log(`- $ueye: ${result.commands.typecheck || result.commands.build || 'Browser/screenshot check; no command detected'}`);
     console.log(`- $deep: ${[result.commands.typecheck, result.commands.lint, result.commands.test, result.commands.build].filter(Boolean).join(' && ') || `No command detected; define in ${PROJECT_PACK}`}`);
     if (result.frameworkChecklist?.detected) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "yam-flow",
-  "version": "2.0.0",
+  "version": "2.1.0",
   "description": "Progressive proof-first agent flow: start fast, deepen deliberately, stay honest by design.",
   "type": "module",
   "author": "0kim0bos",

package/references/final-report.md

@@ -4,10 +4,10 @@ Every `yam` route should end with a compact handoff that helps the next run avoi
 
 ## Required Closing Check
 
-Include these when they are useful and keep them short:
+Always keep final reports short. Include these when they apply:
 
 - What changed or what was found.
-- Change insight for non-specialists: what the touched code does, how it changed, and why it matters.
+- Change insight for non-specialists: what the touched code or artifact does, what role it has, what changed, what behavior is expected, and what remains uncertain.
 - What verification ran.
 - What was not checked.
 - Truth status, when verification or runtime claims matter.
@@ -16,7 +16,7 @@ Include these when they are useful and keep them short:
 - Context pressure or cleanup findings when they could affect the next run.
 - Publish blocker evidence when npm/release work fails.
 - Structured diagnostic next action, when a check found a concrete next step.
-- Study Note for implementation work: what code was wrong, what role it has, how the symptom showed up, what changed, and why it matters in short non-specialist language.
+- Study Note whenever code, config, release metadata, documentation, or project artifacts changed, even if no yam skill was explicitly invoked. This item is required for changed artifacts, not optional.
 - Remaining tasks.
 - Fix-first items before planned tasks.
 - Recommended direction and why that next step matters when the handoff would otherwise be ambiguous.
@@ -58,15 +58,19 @@ Examples:
 
 ## Study Note
 
-Use this when implementation changed code or fixed an error and the user would benefit from learning:
+Use this whenever implementation changed code or any project artifact changed:
 
-- What code had the issue.
-- What role that code plays.
-- How the issue showed up.
-- What changed.
-- Why the change matters.
+- What code or artifact changed.
+- What role that code or artifact plays in the project.
+- What was wrong, missing, unclear, or risky.
+- What changed and what behavior the change should produce.
+- One small syntax, API, schema, or structure insight for a non-specialist.
+- What was verified, or why verification is partial/skipped/blocked.
+- What remains uncertain.
 
-Keep it short. If the information is not known, say so instead of inventing it.
+Keep it short: 4-7 lines for ordinary work, longer only when risk, learning value, `$deep`, `$mission`, release, runtime, or DB work justifies it. If the information is not known, say so instead of inventing it.
+
+Use `references/study-note.md`.
 
 ## Handoff Direction
 

package/references/honest-completion.md

@@ -35,6 +35,19 @@ Verification: not run; change was limited to copy/CSS and inspected locally.
 
 For larger work, include proof summary and residual risk.
 
+Use the L0-L5 Verification Ladder:
+
+- L0 stated.
+- L1 inspected.
+- L2 local check.
+- L3 integrated.
+- L4 release/runtime/visual proof.
+- L5 bounded deep.
+
+Escalate when the claim touches public release, UI done, auth, payment, DB, runtime, deployment, broad refactor, security, high learning value, or explicit user intent.
+
+Bounded heavy verification must stop after the smallest meaningful proof set passes, or after three relevant checks have run and remaining uncertainty is listed as blocked, skipped, or remaining work.
+
 ## Runtime Guard
 
 Runtime work needs stronger evidence because long-running processes can create false success:

package/references/study-note.md

@@ -0,0 +1,53 @@
+# Study Note
+
+Study Note is required whenever code, config, release metadata, documentation, or project artifacts changed, even if no yam skill was explicitly invoked.
+
+The goal is not to write a tutorial for every change. The goal is to help a non-specialist learn the meaning of the changed code a little at a time, without hiding uncertainty or padding the final report.
+
+## Final Report Shape
+
+This is final-report writing guidance, not a new CLI JSON schema. The current CLI artifact remains `yam.study-note.v1` with `problem`, `change`, `why_it_matters`, `learning_note`, `limits`, and `truth_status`. When using `yam loop report`, map the guidance below into the existing fields and put unknowns in `limits`.
+
+Keep the default note short: 4-7 lines for ordinary work, longer only for `$deep`, `$mission`, release, DB, runtime, or learning-heavy work.
+
+Include:
+
+- Touched code/artifact: the file, function, component, config, or artifact that changed.
+- Code/artifact role: what that code or artifact does in the project.
+- Problem meaning: what was wrong, missing, unclear, or risky, and how the symptom appeared.
+- Change meaning: what changed and what behavior the change should produce.
+- Syntax or structure insight: one small language, API, schema, or structure insight for a non-specialist.
+- Verification note: what was checked, or why verification is partial/skipped/blocked.
+- Limits: what is not known; do not invent missing cause, behavior, or verification.
+
+## Compact Example
+
+```text
+Study Note:
+- Touched code: `buildLoopReport`, the function that turns loop inputs into report JSON.
+- Code role: it decides whether a loop can honestly say it is verified, partial, or blocked.
+- Problem meaning: a report could include unfinished requirements without making the completion risk obvious.
+- Change meaning: `uncovered_requirements` now lowers the truth status to blocked and points the next action at the missing requirement.
+- Syntax/structure: the code uses an array length check plus a conditional default to choose safer report fields.
+- Verification: typecheck and CLI smoke covered the JSON shape.
+- Limits: this does not infer requirements from prose; the agent/user still has to provide them.
+```
+
+## When Nothing Changed
+
+For pure Q&A, planning, scouting, or review with no changed artifact, do not force a Study Note. Say `No code or project artifact changed` when that prevents ambiguity.
+
+## Tone
+
+- Use plain language before implementation jargon.
+- Explain the code's responsibility before explaining the patch.
+- Prefer one practical syntax or structure insight over broad teaching.
+- Tie the note to evidence. If no check ran, say so.
+- Keep remaining tasks separate from Study Note.
+
+## What To Avoid
+
+- Do not guess root cause when it was not verified.
+- Do not over-explain common syntax when it distracts from the touched code.
+- Do not turn every final report into a long lesson.
+- Do not claim the user learned something; just leave a useful learning path.

package/references/tool-trust-layer.md

@@ -13,7 +13,8 @@ Every route carries a basic contract:
 - use context packs or memory before broad re-reading
 - verify only what was actually checked
 - report remaining tasks and fix-first issues when useful
-- explain what changed in plain language when code or behavior changes
+- include a Study Note when code, config, release metadata, documentation, or project artifacts changed
+- explain what changed, what role it has, what behavior is expected, and one useful syntax or structure insight in plain language
 - treat security as the first project lens
 - preserve source boundaries when outside references shaped the judgment
 
@@ -26,6 +27,8 @@ Then depth increases by route:
 - `$deep`: prove risky single-agent work with stronger runtime/tool evidence.
 - `$mission`: coordinate real subagents/team lanes with cross-verification.
 
+Verification should follow the L0-L5 ladder: stated, inspected, local check, integrated, release/runtime/visual proof, bounded deep. Serious claims can require serious evidence, but stop after the smallest meaningful proof set passes or after remaining uncertainty is clearly handed off.
+
 ## Surfaces To Wrap
 
 - Local CLI/app readiness.
@@ -94,6 +97,8 @@ On demand:
 
 - What the touched code or artifact is responsible for.
 - What changed in behavior, contract, UI, or safety posture.
+- What syntax, schema, or structure insight helps a non-specialist understand the change.
+- What verification level supports the claim.
 - Why the change matters to the product or user.
 - What remains uncertain or unverified.
 - What should be fixed first before the next planned task.

package/references/verification-levels.md

@@ -1,53 +1,158 @@
-# Verification Levels
+# Verification Ladder
 
-## Level 0: Read/Inspect
+`yam` starts with momentum, but it is not lightweight-only. Verification should become heavier when scope, risk, public release, runtime state, UI completion, auth, DB, broad refactor, or user intent makes false completion costly.
 
-For copy, spacing, small CSS, docs, or no-runtime changes.
+Use the smallest level that honestly supports the claim, then escalate deliberately.
+
+## L0: Stated
+
+Explanation only. No code or artifact was inspected deeply enough to support an implementation claim.
+
+Use for:
+
+- Pure Q&A.
+- Early plan or hypothesis.
+- Scout recommendation before implementation.
+
+Report:
+
+- Truth status: `assumed` or `skipped`.
+- Say no verification ran.
+
+## L1: Inspected
+
+Relevant file, snippet, error, screenshot, or project context was read.
+
+Use for:
+
+- Tiny docs/copy/config edits.
+- Local explanation based on source reading.
+- First pass on a small bug.
 
 Expected:
 
-- Re-read the changed file or relevant snippet.
+- Re-read the changed snippet.
 - Check local project fit.
-- Report that no command was run.
+- Report that no command ran if none did.
 
-## Level 1: One Relevant Check
+Truth cap:
 
-For small JS/TS/component changes.
+- Usually `partial` or `assumed`, not `verified`.
+
+## L2: Local Check
+
+One focused local check supports the claim.
+
+Use for:
+
+- Small TS/JS/app logic changes.
+- Narrow bug fixes.
+- Focused build/type/lint/test failures.
 
 Examples:
 
-- One focused test.
 - Typecheck.
 - Lint for touched area.
+- One focused test.
+- Small CLI smoke for the touched command.
+
+Truth cap:
+
+- `verified` only for the checked surface.
+
+## L3: Integrated
 
-## Level 2: Focused Confidence
+The change was checked through a broader local workflow or user-facing path.
 
-For feature-sized work.
+Use for:
+
+- Feature-sized work.
+- Package-facing CLI changes.
+- UI changes with visible behavior.
+- Changes that affect multiple files or flows.
 
 Examples:
 
-- Typecheck plus related test.
-- Build if no narrower test exists.
+- Build.
+- CLI smoke.
+- Relevant workflow command.
+- Browser check or screenshot.
+- UI state/responsive check.
 
-## Level 3: UI Confidence
+Truth cap:
 
-For visible UI changes.
+- `verified` for the exercised workflow.
+- `partial` when important states, devices, or integrations remain untested.
 
-Expected when feasible:
+## L4: Release / Runtime / Visual Proof
 
-- Desktop screenshot or browser check.
-- Mobile viewport check.
-- Check overflow, alignment, contrast, density, and core states.
+Proof artifact or runtime/visual/release evidence supports the claim.
 
-## Level 4: Deep Confidence
+Use for:
 
-For auth, payment, DB, migration, release, broad refactor, or user-requested deep verification.
+- Public release readiness.
+- Runtime process claims.
+- Cleanup claims.
+- Browser or screenshot visual verification.
+- Auth/payment/DB/deployment/security-sensitive changes.
 
 Examples:
 
-- Build.
-- Test suite or relevant suites.
-- Browser QA.
-- Security check.
-- Proof summary.
+- `yam release report --json`.
+- Runtime evidence with process, port, URL, or cleanup observation.
+- Ueye visual report with screenshot/provenance.
+- DB/security readiness report.
+- Readiness receipt or proof bundle.
+
+Truth cap:
+
+- `proven` only when runtime/process evidence exists.
+- `verified` only when the relevant check actually passed.
+- `blocked` when auth/tool/runtime evidence is required but unavailable.
+
+## L5: Bounded Deep
+
+Multiple relevant checks are combined, with a stop condition, skipped checks, residual risk, and handoff.
+
+Use for:
+
+- Broad refactors.
+- Release candidates.
+- Risky auth/payment/DB/runtime/deployment work.
+- User-requested deep verification.
+- Work with high learning value or high false-completion cost.
+
+Expected:
+
+- Define acceptance criteria.
+- Run the relevant set of checks, not every possible check.
+- Record proof summary or proof bundle lite.
+- List skipped checks and why.
+- List residual risks and remaining tasks.
+
+Stop condition:
+
+- Stop after the smallest meaningful verification set has passed, or after three relevant checks have run and any remaining uncertainty is clearly listed as blocked/remaining work.
+- Stop earlier when the same blocker repeats, a required tool/auth/runtime is unavailable, or a user decision is needed.
+- Do not keep retrying the same failure. Classify `failure_cause`, give `recovery_hint`, and hand off.
+
+## Route Defaults
+
+- `$question`: L0-L1.
+- `$scout`: L0-L1 for judgment; source-backed but not implementation verification.
+- `$quick`: L1-L2 by default; L3 only when the claim needs it.
+- `$ueye`: L1-L3 for ordinary UI work; L4 when claiming visual done.
+- `$deep`: L3-L5 when risk or user intent calls for strong verification.
+- `$mission`: L4-L5 when real subagents/team lanes are used, with cross-verification.
+
+## Completion Claim Rule
+
+Completion claims require evidence at or above the level implied by the claim:
+
+- Code changed: at least L1, preferably L2.
+- User-facing behavior changed: L2-L3.
+- UI done claim: L3-L4 with visual evidence when feasible.
+- Runtime/cleanup claim: L4.
+- Release/auth/DB/security claim: L4-L5.
 
+If the evidence level is lower than the claim, lower the truth status and report the gap.

package/skills/deep/SKILL.md

@@ -43,7 +43,7 @@ Use for:
 
 ## Verification
 
-Use Level 4 from `references/verification-levels.md`.
+Use L3-L5 from `references/verification-levels.md`; pick the smallest bounded set that honestly supports the claim.
 Use `references/token-economy.md`; wider context is allowed only when tied to the risk surface.
 Use `references/context-reuse.md`; update stale project packs narrowly when needed.
 Use `references/markdown-management.md` before writing broad proof or direction markdown.
@@ -52,6 +52,7 @@ Use `references/db-supabase-safety-lite.md` for destructive DB/Supabase, migrati
 Use `references/current-docs.md` when SDK/API/cloud-service behavior may be current or version-sensitive.
 Use `references/trust-kernel.md` when the task asks how yam prevents false completion or fake real proof claims.
 Use `references/honest-completion.md`; do not overclaim verification, runtime, cleanup, or visual proof.
+Use `references/study-note.md` when any code, config, docs, release metadata, or project artifact changed.
 Use `references/final-report.md` to close with remaining tasks and fix-first items when useful.
 Use `references/token-budget-reporter.md` when a run needs measured budget feedback.
 
@@ -65,12 +66,18 @@ Deep verification may include:
 - Before/after screenshot.
 - Risk-specific manual inspection.
 
+Stop condition:
+
+- Stop after the smallest meaningful verification set has passed, or after three relevant checks have run and the remaining uncertainty is clearly listed as blocked/remaining work.
+- Stop earlier when the same blocker repeats, a required tool/auth/runtime is unavailable, or a user decision is needed.
+- Do not keep retrying the same failure; classify the cause, give a recovery hint, and hand off.
+
 ## Final Response
 
 Include:
 
 - What was changed or reviewed.
-- Study Note for implementation work: what code was wrong, what role it has, how the symptom showed up, what changed, and why it matters in short non-specialist language.
+- Study Note for changed artifacts: what changed, what role it has, what was wrong or missing, what behavior is expected, one useful syntax/structure insight, what was verified, and what remains uncertain.
 - Evidence gathered.
 - Truth status.
 - Blockers or remaining risk.

package/skills/mission/SKILL.md

@@ -58,6 +58,12 @@ Do not use for:
 12. Confirm cleanup or explicitly report intentionally running processes.
 13. Produce final proof summary, truth status, remaining tasks, and fix-first items.
 
+Mission stop condition:
+
+- Stop after cross-verification and the smallest meaningful L4-L5 proof set have passed, or after three relevant checks have run and remaining uncertainty is recorded as blocked/remaining work.
+- Stop earlier when the same blocker repeats, a required tool/auth/runtime is unavailable, or a user decision is needed.
+- Do not keep retrying the same failure; classify the cause, give a recovery hint, and hand off.
+
 ## Proof Summary
 
 Include:
@@ -79,7 +85,9 @@ Use `references/runtime-orchestration.md` only when runtime evidence is needed.
 Use `references/doctor-scan.md` before final mission completion.
 Use `references/db-supabase-safety-lite.md` for destructive DB/Supabase, migration, production-write, or RLS/policy lanes.
 Use `references/current-docs.md` when any lane depends on current SDK/API/cloud-service behavior.
+Use `references/verification-levels.md` for L4-L5 mission proof boundaries.
 Use `references/honest-completion.md`; do not overclaim.
+Use `references/study-note.md` for every lane that changes code, config, docs, release metadata, or project artifacts.
 Use `references/final-report.md` to close with remaining tasks and fix-first items.
 Use `references/token-budget-reporter.md` when budget drift matters.
 
@@ -102,7 +110,7 @@ Report:
 
 - What the mission changed.
 - Role/cross-verification summary.
-- Study Note for implementation lanes: what code was wrong, what role it has, how the symptom showed up, what changed, and why it matters in short non-specialist language.
+- Study Note for any lane that changed code, config, docs, release metadata, or project artifacts: what changed, what role it has, what was wrong or missing, what behavior is expected, one useful syntax/structure insight, what was verified, and what remains uncertain.
 - Evidence gathered.
 - Truth status.
 - Cleanup status.

package/skills/quick/SKILL.md

@@ -58,16 +58,19 @@ Scan lane:
 
 ## Verification
 
-- Copy/CSS/docs: Level 0 is often enough after re-reading the changed snippet.
+- Copy/CSS/docs: L1 is often enough after re-reading the changed snippet.
 - TS/JS or app logic: prefer typecheck, related test, lint, or build in that order when available.
 - Build-fix: use a compact PASS/FAIL matrix for command results.
 - If verification is skipped, partial, blocked, or assumed, say that plainly.
+- Escalate beyond L2 only when the changed behavior, user-facing impact, or risk surface needs it.
 
 Use `references/quick.md` for the merged fast/build rules.
+Use `references/verification-levels.md` for the L0-L5 ladder.
 Use `references/truth-matrix.md` for truth labels.
 Use `references/db-supabase-safety-lite.md` when a command or prompt contains DB/Supabase mutation signals.
 Use `references/token-economy.md` to keep context small.
 Use `references/context-reuse.md` before broad project reading.
+Use `references/study-note.md` when any code, config, docs, or project artifact changed.
 Use `references/final-report.md` to close with remaining tasks and fix-first items when useful.
 Use `references/token-budget-reporter.md` when a run needs measured budget feedback.
 
@@ -76,7 +79,7 @@ Use `references/token-budget-reporter.md` when a run needs measured budget feedb
 Keep it compact:
 
 - What changed or what the scan found.
-- Study Note when useful: what code was wrong, what role it has, how the symptom showed up, what changed, and why it matters in short non-specialist language.
+- Study Note when code, config, docs, or project artifacts changed: what changed, what role it has, what was wrong or missing, what behavior is expected, one useful syntax/structure insight, what was verified, and what remains uncertain.
 - What was checked.
 - What was skipped, blocked, or still risky.
 - Handoff when useful: fix-first items, remaining tasks, recommended direction, why that next step matters, blocker kind, safe retry, evidence level/stamp, and owner scope when another route or person may continue.

package/skills/ueye/SKILL.md

@@ -43,6 +43,7 @@ Do not use for:
 - Prefer the in-app browser for interactive visual checks. Do not switch to a profile-dependent browser unless the user explicitly asks or the task requires existing cookies, sessions, extensions, or profile state.
 - Ueye owns the design completion gate. Do not rely on a separate code-risk route to catch sloppy visual completion.
 - Draft or needs-polish work may stay fast; a `done` claim requires recorded design gate evidence.
+- Use the Verification Ladder: ordinary UI implementation can stay L1-L3, but a visual `done` claim needs L3-L4 evidence when feasible.
 - Do not claim a Ueye result is done when implementation evidence, design quality, P0/P1 status, state coverage, mobile/responsive behavior, contrast/accessibility visuals, CTA affordance, or reference-read/comparison evidence is missing where relevant.
 
 ## Workflow
@@ -145,6 +146,8 @@ Use these artifacts for reference-led implementation or serious visual review. K
 ## Design Checks
 
 Use `references/ueye.md` and `references/ui-quality.md`.
+Use `references/verification-levels.md` for visual proof levels and done-claim truth caps.
+Use `references/study-note.md` when UI code, design docs, config, or project artifacts changed.
 Always consider:
 
 - Direction fit.
@@ -170,6 +173,6 @@ Report:
 - Review continuity/comparison result when this continues a prior Ueye run.
 - P0-P3 issues or confirmation that no blockers were found.
 - States/viewports checked.
-- Study Note when UI implementation changed code: what UI code changed, what role it has, how the visible symptom appeared, and why the change matters in short non-specialist language.
+- Study Note when UI code, design docs, config, or project artifacts changed: what changed, what role it has, what was wrong or missing, what behavior is expected, one useful syntax/structure insight, what was verified, and what remains uncertain.
 - Truth status and visual verification cap.
 - Handoff when useful: fix-first visual issues, remaining tasks, recommended direction, why that next step matters, blocker kind, safe retry, evidence level/stamp, and owner scope when another route or person may continue.

package/src/bin/yam.ts

@@ -346,6 +346,7 @@ async function verify({ quiet = false } = {}) {
     'token-economy.md',
     'context-reuse.md',
     'markdown-management.md',
+    'study-note.md',
     'final-report.md',
     'token-budget-reporter.md',
     'memory.md'
@@ -3776,7 +3777,7 @@ function printDetection(result) {
   }
   console.log('');
   console.log('Smallest useful checks:');
-  console.log(`- $quick: ${result.commands.typecheck || result.commands.lint || result.commands.test || result.commands.build || 'Level 0 read/inspect; no command detected'}`);
+  console.log(`- $quick: ${result.commands.typecheck || result.commands.lint || result.commands.test || result.commands.build || 'L1 inspected; no command detected'}`);
   console.log(`- $ueye: ${result.commands.typecheck || result.commands.build || 'Browser/screenshot check; no command detected'}`);
   console.log(`- $deep: ${[result.commands.typecheck, result.commands.lint, result.commands.test, result.commands.build].filter(Boolean).join(' && ') || `No command detected; define in ${PROJECT_PACK}`}`);
   if (result.frameworkChecklist?.detected) {

package/templates/yam.project.md

@@ -44,6 +44,8 @@
 - UI changes:
 - Feature changes:
 - Risky changes:
+- Verification ladder: L0 stated, L1 inspected, L2 local check, L3 integrated, L4 release/runtime/visual proof, L5 bounded deep.
+- Stop condition for heavy verification:
 - Public/release changes: scan for external tool names, comparison wording, and attribution wording; remove those hits unless the user explicitly approves keeping them.
 
 ## Security Policy
@@ -56,7 +58,8 @@
 
 ## Report Policy
 
-- Explain changed code in plain language:
+- Study Note requirement for changed code/config/release metadata/docs/artifacts:
+- Explain touched code or artifact role, changed behavior, one syntax/structure insight, verification, and uncertainty:
 - Always include remaining tasks or useful improvements:
 - Preserve source boundaries for research/proof notes:
 

package/yam.manifest.json

@@ -1,6 +1,6 @@
 {
   "name": "yam",
-  "version": "2.0.0",
+  "version": "2.1.0",
   "principles": [
     "Direction before execution.",
     "Start fast.",
@@ -11,8 +11,10 @@
     "Token-aware by default.",
     "Context-reuse first.",
     "End with remaining tasks and fix-first items.",
-    "Explain what failed, what changed, and why it matters in short non-specialist language when useful.",
-    "Use handoff notes for fix-first items, remaining tasks, recommended next direction, requirement coverage, blocker kind, failure cause, recovery hint, safe retry, evidence level, and owner scope when useful."
+    "When code, config, release metadata, documentation, or project artifacts changed, include a Study Note even if no yam skill was explicitly invoked.",
+    "Explain what changed, what role it has, what was wrong or missing when relevant, what behavior is expected, and one useful syntax or structure insight in short non-specialist language.",
+    "Use handoff notes for fix-first items, remaining tasks, recommended next direction, requirement coverage, blocker kind, failure cause, recovery hint, safe retry, evidence level, and owner scope when useful.",
+    "Use bounded heavy verification for serious claims, with explicit stop conditions instead of endless proof loops."
   ],
   "defaultHooks": false,
   "routes": [