yam-flow 1.9.1 → 2.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/AGENTS.md CHANGED
@@ -8,14 +8,15 @@
8
8
  6. Check local project fit before changing code, even for small work.
9
9
  7. Prefer existing project patterns over new abstractions.
10
10
  8. Make the smallest useful change.
11
- 9. Verify at the lightest level that honestly supports the claim, then escalate verification when the claim is larger.
11
+ 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.
12
12
  10. Report skipped, partial, blocked, or assumed verification plainly.
13
13
  11. Do not run broad tests for tiny changes, but do not under-verify risky, security-sensitive, or public work.
14
14
  12. Do not use teams, orchestration, structured proof, or tmux unless risk, user intent, learning value, or an approved route justifies it.
15
15
  13. Escalate risky work by asking or recommending, not by silently switching modes.
16
16
  14. For UI work, inspect real states and responsive behavior when feasible.
17
17
  15. For long-running processes, do not claim cleanup unless process exit is checked.
18
- 16. Explain useful change insight for non-specialists: what the touched code does, what changed, and why it matters.
19
- 17. Use external references deliberately, preserve source clarity in research/proof notes, and rework good ideas into yam style.
20
- 18. Treat security as the first project lens: identify sensitive surfaces early and guide safer defaults before convenience.
21
- 19. Keep final reports short and concrete, but always include remaining tasks or state that none are meaningful.
18
+ 16. When code, config, release metadata, documentation, or project artifacts changed, include a Study Note even if no yam skill was explicitly invoked.
19
+ 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.
20
+ 18. Use external references deliberately, preserve source clarity in research/proof notes, and rework good ideas into yam style.
21
+ 19. Treat security as the first project lens: identify sensitive surfaces early and guide safer defaults before convenience.
22
+ 20. Keep final reports short and concrete, but always include remaining tasks or state that none are meaningful.
package/CHANGELOG.md CHANGED
@@ -2,6 +2,39 @@
2
2
 
3
3
  All notable changes to yam-flow are documented here.
4
4
 
5
+ ## v2.1.0 - 2026-06-30
6
+
7
+ ### Added
8
+
9
+ - Added `references/study-note.md` with required Study Note guidance for any changed code, config, release metadata, documentation, or project artifact.
10
+ - 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.
11
+
12
+ ### Improved
13
+
14
+ - 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.
15
+ - 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.
16
+
17
+ ## v2.0.0 - 2026-06-24
18
+
19
+ ### Added
20
+
21
+ - Extended `yam loop report --json` with lightweight requirement coverage, `failure_cause`, `recovery_hint`, and `avoidance_note` so handoff artifacts can show what must still be covered before a completion claim.
22
+ - Added `readiness_receipt` to `yam release report --json` to summarize the read-only evidence basis for package/version, registry, auth, git, dist, tarball, and release-check readiness.
23
+
24
+ ### Improved
25
+
26
+ - Uncovered loop requirements now block verified truth, default `blocked_kind` to `requirement_uncovered`, and point the default next action at the first uncovered requirement.
27
+ - Documented that loop avoidance notes are report-only; durable learning remains explicit through `yam memory add`.
28
+
29
+ ### Verification
30
+
31
+ - `npm run typecheck`
32
+ - `npm run build`
33
+ - `npm run cli-smoke`
34
+ - `npm run verify:self`
35
+ - `node ./dist/bin/yam.js loop report --json` with uncovered requirement truth blocking
36
+ - `node ./dist/bin/yam.js release report --json` (blocked as expected by npm auth readiness and dirty git, with `readiness_receipt`)
37
+
5
38
  ## v1.9.1 - 2026-06-19
6
39
 
7
40
  ### Added
package/COMMANDS.md CHANGED
@@ -148,7 +148,7 @@ yam tools doctor /path/to/project
148
148
  yam tools doctor /path/to/project --json
149
149
  yam context pressure /path/to/project --json
150
150
  yam cleanup scan /path/to/project --json
151
- yam loop report --route quick --intent "fix release readiness" --stage "inspect:passed:read release report" --evidence "typecheck passed" --evidence-level local --evidence-stamp "sha256:release-report" --blocked-kind auth_blocked --safe-retry "retry after npm whoami succeeds" --fix-first-item "npm auth must be verified before publish" --remaining-task "rerun release report after auth refresh" --recommended-direction "fix npm auth first, then publish manually" --implementation-note "keep loop report read-only" --why-this-next "auth blocks public release claims" --blocked-by "npm whoami E401" --owner-route deep --owner-scope "release readiness only" --scope-owner deep --side-effect "no publish attempted" --issue-code "src/bin/yam.ts release report" --issue-role "summarizes release readiness without publishing" --issue-symptom "npm auth failure needs clearer next action" --changed-code "yam loop report" --changed-role "records loop evidence and learning note" --change-summary "added a read-only loop artifact" --why-important "it helps users learn what changed without overclaiming verification" --learning-note "fix blockers before claiming done" --json
151
+ yam loop report --route quick --intent "fix release readiness" --stage "inspect:passed:read release report" --evidence "typecheck passed" --evidence-level local --evidence-stamp "sha256:release-report" --covered-requirement "release report is read-only" --uncovered-requirement "npm auth verified" --blocked-kind auth_blocked --failure-cause auth_token_invalid --safe-retry "retry after npm whoami succeeds" --recovery-hint "refresh npm auth, then rerun readiness checks" --fix-first-item "npm auth must be verified before publish" --remaining-task "rerun release report after auth refresh" --recommended-direction "fix npm auth first, then publish manually" --implementation-note "keep loop report read-only" --why-this-next "auth blocks public release claims" --blocked-by "npm whoami E401" --owner-route deep --owner-scope "release readiness only" --scope-owner deep --side-effect "no publish attempted" --avoidance-note "do not retry publish before npm auth is proven" --issue-code "src/bin/yam.ts release report" --issue-role "summarizes release readiness without publishing" --issue-symptom "npm auth failure needs clearer next action" --changed-code "yam loop report" --changed-role "records loop evidence and learning note" --change-summary "added a read-only loop artifact" --why-important "it helps users learn what changed without overclaiming verification" --learning-note "fix blockers before claiming done" --json
152
152
  yam proof /path/to/project
153
153
  yam proof --route deep --truth verified --command "npm run build: pass"
154
154
  yam proof --route ueye --truth verified --visual "reference image only"
@@ -195,8 +195,9 @@ Supported report shapes:
195
195
 
196
196
  - Runtime evidence mini: command/process, observation, cleanup, truth status, next action.
197
197
  - Patch queue lite: mission lane status, changed files, verification hint, rollback hint, truth status.
198
+ - 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.
198
199
  - 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.
199
- - Study note: short non-specialist explanation of the failing code, its role, observed symptom, changed code, and why it matters.
200
+ - 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.
200
201
  - Benchmark optimization loop lite: baseline, one change, rerun, keep/revert decision.
201
202
  - Structured diagnostic next action: severity, evidence, owner route, next action, truth status.
202
203
  - Ueye continuity/comparison: previous report, current report, comparison delta, design quality, next action.
package/DECISIONS.md CHANGED
@@ -38,11 +38,14 @@ Every `yam` change is evaluated against honest proof, progressive depth, securit
38
38
  - Rules the model can actually follow.
39
39
  - Fast momentum without pretending simple work is always enough.
40
40
  - Depth growth when the user's understanding, project risk, or product quality benefits from it.
41
+ - L0-L5 verification ladder with bounded heavy verification and explicit stop conditions.
41
42
 
42
43
  ### Beginner Insight
43
44
 
44
45
  - Explain changed behavior in plain language.
45
46
  - Name the code area touched and what it is responsible for.
47
+ - Include Study Note whenever code, config, release metadata, documentation, or project artifacts changed.
48
+ - Teach one useful syntax, schema, or structure insight without turning the final report into a long tutorial.
46
49
  - Separate implementation facts from judgment.
47
50
  - Always close with remaining tasks or useful improvements.
48
51
 
package/README.md CHANGED
@@ -14,6 +14,8 @@ Context-reuse first.
14
14
  End with remaining tasks and fix-first items.
15
15
  Security-first project guidance.
16
16
  Useful change insight for non-specialists.
17
+ Study Note for changed artifacts.
18
+ Verification Ladder for larger claims.
17
19
  Reference-led judgment with clear source boundaries.
18
20
  ```
19
21
 
@@ -31,17 +33,18 @@ See `ROADMAP.md` for remaining implementation stages.
31
33
 
32
34
  ## Defaults
33
35
 
34
- - No hooks.
36
+ - No required hooks.
35
37
  - Optional `yam-lite` hook is advisory-only and off by default.
36
38
  - No automatic Team routing.
37
39
  - No automatic proof loops.
38
40
  - No automatic tmux.
39
41
  - No false completion claims: verification, cleanup, and visual checks must match actual evidence.
40
42
  - `yam` is not lightweight-only; it is progressive: fast direction, broader judgment when useful, stronger proof as scope/risk grows.
41
- - Every route should check project direction and use an honest verification level.
43
+ - Every route should check project direction and use the L0-L5 Verification Ladder honestly.
42
44
  - Small work stays small, but serious work is allowed to become serious.
43
45
  - Security-sensitive work is never treated as ordinary polish.
44
- - Useful reports explain what the changed code does, how it changed, and why the change matters.
46
+ - When code, config, release metadata, documentation, or project artifacts changed, final reports include a Study Note even if no yam skill was invoked.
47
+ - 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.
45
48
  - Research and reference scans should keep source boundaries clear, then rework good ideas into yam style.
46
49
  - Token economy is part of quality.
47
50
  - Project packs prevent re-reading and re-planning from scratch.
@@ -142,7 +145,7 @@ yam ueye report --reference ./reference.png --actual .yam/screens/home.png --pre
142
145
  yam proof --route ueye --truth verified --visual "implementation screenshot evidence recorded" --design-completion '{"completion_claim":"done","has_implementation_screenshot":true,"design_quality":"pass","states_checked":true,"mobile_checked":true,"contrast_checked":true,"cta_checked":true,"direction_locked":true,"truth_status":"verified"}'
143
146
  yam media proof --requested --attempted --output ./generated.png --wait-loop --json
144
147
  yam proof --route mission --mission-envelope '{"agent_id":"implementer","assigned_scope":"target component","changed_files":["src/file.ts"],"verification_hint":"npm run typecheck","truth_status":"partial"}'
145
- yam loop report --route quick --intent "fix release readiness" --stage "inspect:passed:read release report" --evidence "typecheck passed" --evidence-level local --evidence-stamp "sha256:release-report" --blocked-kind auth_blocked --safe-retry "retry after npm whoami succeeds" --fix-first-item "npm auth must be verified before publish" --remaining-task "rerun release report after auth refresh" --recommended-direction "fix npm auth first, then publish manually" --implementation-note "keep loop report read-only" --why-this-next "auth blocks public release claims" --blocked-by "npm whoami E401" --owner-route deep --owner-scope "release readiness only" --scope-owner deep --side-effect "no publish attempted" --issue-code "src/bin/yam.ts release report" --issue-role "summarizes release readiness without publishing" --issue-symptom "npm auth failure needs clearer next action" --changed-code "yam loop report" --changed-role "records loop evidence and learning note" --change-summary "added a read-only loop artifact" --why-important "it helps users learn what changed without overclaiming verification" --learning-note "fix blockers before claiming done" --json
148
+ yam loop report --route quick --intent "fix release readiness" --stage "inspect:passed:read release report" --evidence "typecheck passed" --evidence-level local --evidence-stamp "sha256:release-report" --covered-requirement "release report is read-only" --uncovered-requirement "npm auth verified" --blocked-kind auth_blocked --failure-cause auth_token_invalid --safe-retry "retry after npm whoami succeeds" --recovery-hint "refresh npm auth, then rerun readiness checks" --fix-first-item "npm auth must be verified before publish" --remaining-task "rerun release report after auth refresh" --recommended-direction "fix npm auth first, then publish manually" --implementation-note "keep loop report read-only" --why-this-next "auth blocks public release claims" --blocked-by "npm whoami E401" --owner-route deep --owner-scope "release readiness only" --scope-owner deep --side-effect "no publish attempted" --avoidance-note "do not retry publish before npm auth is proven" --issue-code "src/bin/yam.ts release report" --issue-role "summarizes release readiness without publishing" --issue-symptom "npm auth failure needs clearer next action" --changed-code "yam loop report" --changed-role "records loop evidence and learning note" --change-summary "added a read-only loop artifact" --why-important "it helps users learn what changed without overclaiming verification" --learning-note "fix blockers before claiming done" --json
146
149
  yam release report --json
147
150
  yam safety "supabase db reset"
148
151
  yam detect /path/to/project
@@ -215,11 +218,13 @@ These shapes keep reports machine-readable without turning normal work into a he
215
218
 
216
219
  - Runtime evidence mini: compact route, command/process, observation, cleanup, truth status, and next action fields for `$deep` or `$mission` runtime claims.
217
220
  - Patch queue lite: `$mission` lane records with pending/applied/verified/reverted/blocked state, changed files, verification hint, rollback hint, truth status, and next action.
218
- - Release report JSON: `yam release report --json` summarizes typecheck, forbidden-name scan, package boundary, registry status, CLI smoke, dist freshness, diagnostics, and final truth status.
219
- - Loop report JSON: `yam loop report --json` records a read-only handoff artifact: guided stages, evidence level/stamp, blocker kind, safe retry, owner route/scope, side effects, next action, fix-first items, remaining tasks, recommended direction, implementation notes, blocked-by notes, tool intent, truth status, and study note.
220
- - 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.
221
+ - 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.
222
+ - 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.
223
+ - 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.
224
+ - 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.
225
+ - 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`.
221
226
  - Publish blocker evidence: release reports classify common npm auth, permission, OTP, immutable-version, cache, registry, and tarball failures into safe next actions.
222
- - Publish readiness evidence: release reports run read-only registry/auth/version probes, redact account/token details, and keep npm publish outside the report.
227
+ - 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.
223
228
  - Context pressure: `yam context pressure` explains when project context is getting stale, broad, or confusing enough to summarize, refresh, narrow scope, or deepen route.
224
229
  - Cleanup scan: `yam cleanup scan` is read-only and advisory; it reports confusing hooks, local skill folders, stale traces, or old proof artifacts without deleting anything.
225
230
  - Benchmark optimization loop lite: use `yam measure <route>` and `yam template tuning` to record baseline, one route wording change, rerun result, keep/revert decision, and stop condition.
package/dist/bin/yam.js CHANGED
@@ -318,6 +318,7 @@ async function verify({ quiet = false } = {}) {
318
318
  'token-economy.md',
319
319
  'context-reuse.md',
320
320
  'markdown-management.md',
321
+ 'study-note.md',
321
322
  'final-report.md',
322
323
  'token-budget-reporter.md',
323
324
  'memory.md'
@@ -1586,6 +1587,7 @@ function runReleaseReport() {
1586
1587
  const publishReadiness = releasePublishReadiness(checks, provenance, tarball, publishBlockerEvidence);
1587
1588
  const nextActions = releaseNextActions(checks, provenance, tarball, publishBlockerEvidence, publishReadiness);
1588
1589
  const ok = failed.length === 0 && publishReadiness.status === 'ready';
1590
+ const readinessReceipt = releaseReadinessReceipt(provenance, freshness, tarball, publishReadiness, ok);
1589
1591
  return {
1590
1592
  schema: 'yam.release-report.v1',
1591
1593
  generated_at: startedAt,
@@ -1599,11 +1601,53 @@ function runReleaseReport() {
1599
1601
  tarball,
1600
1602
  freshness,
1601
1603
  publish_readiness: publishReadiness,
1604
+ readiness_receipt: readinessReceipt,
1602
1605
  study_note: releaseStudyNote(publishReadiness, publishBlockerEvidence),
1603
1606
  publishBlockerEvidence,
1604
1607
  next_actions: nextActions
1605
1608
  };
1606
1609
  }
1610
+ function releaseReadinessReceipt(provenance = {}, freshness = {}, tarball = {}, publishReadiness = {}, ok = false) {
1611
+ return {
1612
+ schema: 'yam.release-readiness-receipt.v1',
1613
+ generated_at: new Date().toISOString(),
1614
+ package_name: PACKAGE_JSON.name,
1615
+ local_version: VERSION,
1616
+ registry: {
1617
+ url: String(publishReadiness.registry?.url || ''),
1618
+ latest_version: String(publishReadiness.registry?.latest_version || ''),
1619
+ version_status: String(publishReadiness.registry?.version_status || 'not_verified'),
1620
+ truth_status: publishReadiness.registry?.truth_status || 'partial'
1621
+ },
1622
+ auth: {
1623
+ command: 'npm whoami',
1624
+ status: String(publishReadiness.auth?.status || 'not_verified'),
1625
+ account: publishReadiness.auth?.status === 'authenticated' ? 'observed_redacted' : '',
1626
+ truth_status: publishReadiness.auth?.truth_status || 'partial'
1627
+ },
1628
+ git: {
1629
+ commit: String(provenance.git_commit || ''),
1630
+ dirty: Boolean(provenance.git_dirty),
1631
+ dirty_lines_observed: Array.isArray(provenance.git_status_lines) ? provenance.git_status_lines.length : 0,
1632
+ truth_status: provenance.truth_status || 'partial'
1633
+ },
1634
+ checks: {
1635
+ dist: freshness.dist || 'not-verified',
1636
+ package_boundary: freshness.package_boundary || 'not-verified',
1637
+ cli_smoke: freshness.cli_smoke || 'not-verified',
1638
+ tarball: tarball.status === 'checked' ? 'checked' : 'not-verified'
1639
+ },
1640
+ tarball: {
1641
+ status: String(tarball.status || 'not-verified'),
1642
+ name: String(tarball.tarball_name || ''),
1643
+ integrity_present: Boolean(tarball.integrity),
1644
+ shasum_present: Boolean(tarball.shasum),
1645
+ truth_status: tarball.truth_status || 'partial'
1646
+ },
1647
+ publish_attempted: false,
1648
+ truth_status: ok ? 'verified' : 'blocked'
1649
+ };
1650
+ }
1607
1651
  function releaseProvenance(checks = []) {
1608
1652
  const gitCommit = runReadOnlyCommand('git', ['rev-parse', '--short', 'HEAD']);
1609
1653
  const gitStatus = runReadOnlyCommand('git', ['status', '--short']);
@@ -1979,13 +2023,13 @@ function loopUsage() {
1979
2023
  Read-only loop artifact helpers. A loop report records intent, stages, evidence, blockers, next action, handoff fields, and a short study note. It does not run agents, start processes, publish packages, or write files.
1980
2024
 
1981
2025
  Usage:
1982
- yam loop report [--route route] [--intent text] [--loop-kind harness|release|ueye|scout|deep|mission] [--stage id:status:note] [--evidence text] [--evidence-level none|fixture|smoke|local|real] [--evidence-stamp text] [--source-digest text] [--blocked text] [--blocked-kind text] [--safe-retry text] [--fix-first-item text] [--remaining-task text] [--recommended-direction text] [--implementation-note text] [--why-this-next text] [--blocked-by text] [--owner-route route] [--owner-scope text] [--scope-owner text] [--side-effect text] [--truth status] [--intent-label read_only|write|destructive|runtime|visual|publish] [--issue-code text] [--issue-role text] [--issue-symptom text] [--changed-code text] [--changed-role text] [--change-summary text] [--why-important text] [--learning-note text] [--json]
2026
+ yam loop report [--route route] [--intent text] [--loop-kind harness|release|ueye|scout|deep|mission] [--stage id:status:note] [--evidence text] [--evidence-level none|fixture|smoke|local|real] [--evidence-stamp text] [--source-digest text] [--covered-requirement text] [--uncovered-requirement text] [--blocked text] [--blocked-kind text] [--failure-cause text] [--safe-retry text] [--recovery-hint text] [--fix-first-item text] [--remaining-task text] [--recommended-direction text] [--implementation-note text] [--why-this-next text] [--blocked-by text] [--owner-route route] [--owner-scope text] [--scope-owner text] [--side-effect text] [--avoidance-note text] [--truth status] [--intent-label read_only|write|destructive|runtime|visual|publish] [--issue-code text] [--issue-role text] [--issue-symptom text] [--changed-code text] [--changed-role text] [--change-summary text] [--why-important text] [--learning-note text] [--json]
1983
2027
  `);
1984
2028
  }
1985
2029
  async function loopReport(args = []) {
1986
2030
  if (args[0] === 'help' || args[0] === '--help' || args[0] === '-h')
1987
2031
  return loopUsage();
1988
- const flags = parseSimpleFlags(args, new Set(['route', 'intent', 'loop-kind', 'stage', 'stage-convention', 'evidence', 'evidence-level', 'evidence-stamp', 'source-digest', 'blocked', 'blocker', 'blocked-kind', 'next-action', 'safe-retry', 'fix-first-item', 'remaining-task', 'recommended-direction', 'direction', 'implementation-note', 'why-this-next', 'blocked-by', 'owner-route', 'owner-scope', 'scope-owner', 'owner', 'scope', 'side-effect', 'truth', 'intent-label', 'tool-intent', 'issue-code', 'issue-role', 'issue-symptom', 'changed-code', 'changed-role', 'change-summary', 'why-important', 'learning-note', 'json']));
2032
+ const flags = parseSimpleFlags(args, new Set(['route', 'intent', 'loop-kind', 'stage', 'stage-convention', 'evidence', 'evidence-level', 'evidence-stamp', 'source-digest', 'covered-requirement', 'uncovered-requirement', 'blocked', 'blocker', 'blocked-kind', 'failure-cause', 'next-action', 'safe-retry', 'recovery-hint', 'fix-first-item', 'remaining-task', 'recommended-direction', 'direction', 'implementation-note', 'why-this-next', 'blocked-by', 'owner-route', 'owner-scope', 'scope-owner', 'owner', 'scope', 'side-effect', 'avoidance-note', 'truth', 'intent-label', 'tool-intent', 'issue-code', 'issue-role', 'issue-symptom', 'changed-code', 'changed-role', 'change-summary', 'why-important', 'learning-note', 'json']));
1989
2033
  const blockers = [...arrayFlag(flags.blocked), ...arrayFlag(flags.blocker)];
1990
2034
  const report = buildLoopReport({
1991
2035
  route: normalizeRoute(flags.route) || String(flags.route || ''),
@@ -1997,12 +2041,16 @@ async function loopReport(args = []) {
1997
2041
  evidence_level: normalizeLoopEvidenceLevelFlag(flags.evidence_level),
1998
2042
  evidence_stamp: String(flags.evidence_stamp || ''),
1999
2043
  source_digest: String(flags.source_digest || ''),
2044
+ covered_requirements: arrayFlag(flags.covered_requirement),
2045
+ uncovered_requirements: arrayFlag(flags.uncovered_requirement),
2000
2046
  blockers,
2001
2047
  blocked_kind: String(flags.blocked_kind || ''),
2048
+ failure_cause: String(flags.failure_cause || ''),
2002
2049
  truth_status: isTruthStatus(flags.truth) ? flags.truth : undefined,
2003
2050
  intent_label: normalizeToolIntent(flags.intent_label || flags.tool_intent || 'read_only'),
2004
2051
  next_action: String(flags.next_action || ''),
2005
2052
  safe_retry: String(flags.safe_retry || ''),
2053
+ recovery_hint: String(flags.recovery_hint || ''),
2006
2054
  fix_first_items: arrayFlag(flags.fix_first_item),
2007
2055
  remaining_tasks: arrayFlag(flags.remaining_task),
2008
2056
  recommended_direction: String(flags.recommended_direction || flags.direction || ''),
@@ -2013,6 +2061,7 @@ async function loopReport(args = []) {
2013
2061
  owner_scope: [...arrayFlag(flags.owner_scope), ...arrayFlag(flags.scope)],
2014
2062
  scope_owner: String(flags.scope_owner || flags.owner || ''),
2015
2063
  side_effects: arrayFlag(flags.side_effect),
2064
+ avoidance_note: String(flags.avoidance_note || ''),
2016
2065
  issue_code: String(flags.issue_code || ''),
2017
2066
  issue_role: String(flags.issue_role || ''),
2018
2067
  issue_symptom: String(flags.issue_symptom || ''),
@@ -3734,7 +3783,7 @@ function printDetection(result) {
3734
3783
  }
3735
3784
  console.log('');
3736
3785
  console.log('Smallest useful checks:');
3737
- console.log(`- $quick: ${result.commands.typecheck || result.commands.lint || result.commands.test || result.commands.build || 'Level 0 read/inspect; no command detected'}`);
3786
+ console.log(`- $quick: ${result.commands.typecheck || result.commands.lint || result.commands.test || result.commands.build || 'L1 inspected; no command detected'}`);
3738
3787
  console.log(`- $ueye: ${result.commands.typecheck || result.commands.build || 'Browser/screenshot check; no command detected'}`);
3739
3788
  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}`}`);
3740
3789
  if (result.frameworkChecklist?.detected) {
@@ -161,13 +161,17 @@ export interface LoopReport {
161
161
  evidence_level: LoopEvidenceLevel;
162
162
  evidence_stamp: string;
163
163
  source_digest: string;
164
+ covered_requirements: string[];
165
+ uncovered_requirements: string[];
164
166
  blockers: string[];
165
167
  blocked_kind: string;
168
+ failure_cause: string;
166
169
  truth_status: TruthStatus;
167
170
  intent_label: ToolIntent;
168
171
  tool_intent: ToolIntent;
169
172
  next_action: string;
170
173
  safe_retry: string;
174
+ recovery_hint: string;
171
175
  fix_first_items: string[];
172
176
  remaining_tasks: string[];
173
177
  recommended_direction: string;
@@ -178,6 +182,7 @@ export interface LoopReport {
178
182
  owner_scope: string[];
179
183
  scope_owner: string;
180
184
  side_effects: string[];
185
+ avoidance_note: string;
181
186
  study_note: StudyNote;
182
187
  }
183
188
  export interface UeyeRunReport {
@@ -236,13 +236,18 @@ export function buildLoopReport(input = {}) {
236
236
  ? input.stages.map((stage) => buildLoopStage(stage))
237
237
  : [];
238
238
  const evidence = asList(input.evidence);
239
+ const coveredRequirements = asList(input.covered_requirements || input.covered_requirement);
240
+ const uncoveredRequirements = asList(input.uncovered_requirements || input.uncovered_requirement);
239
241
  const blockers = asList(input.blockers || input.blocked);
240
242
  const blockedBy = asList(input.blocked_by);
241
- const blockedKind = shortText(input.blocked_kind || (blockers.length || blockedBy.length ? 'evidence_missing' : ''));
243
+ const blockedKind = shortText(input.blocked_kind || (uncoveredRequirements.length ? 'requirement_uncovered' : blockers.length || blockedBy.length ? 'evidence_missing' : ''));
244
+ const failureCause = shortText(input.failure_cause);
245
+ const recoveryHint = shortText(input.recovery_hint);
246
+ const avoidanceNote = shortText(input.avoidance_note);
242
247
  const evidenceStamp = shortText(input.evidence_stamp || input.source_digest, 320);
243
248
  const sourceDigest = shortText(input.source_digest || input.evidence_stamp, 320);
244
249
  const hasBlockedStage = stages.some((stage) => stage.status === 'blocked' || stage.status === 'failed');
245
- const hasBlockerSignal = Boolean(blockers.length || blockedBy.length || blockedKind);
250
+ const hasBlockerSignal = Boolean(blockers.length || blockedBy.length || blockedKind || uncoveredRequirements.length);
246
251
  const requestedTruth = isTruthStatus(input.truth_status) ? input.truth_status : '';
247
252
  const derivedTruth = hasBlockerSignal || hasBlockedStage ? 'blocked'
248
253
  : evidence.length && stages.some((stage) => stage.status === 'passed') ? 'verified'
@@ -265,13 +270,17 @@ export function buildLoopReport(input = {}) {
265
270
  evidence_level: normalizeLoopEvidenceLevel(input.evidence_level),
266
271
  evidence_stamp: evidenceStamp,
267
272
  source_digest: sourceDigest,
273
+ covered_requirements: coveredRequirements,
274
+ uncovered_requirements: uncoveredRequirements,
268
275
  blockers,
269
276
  blocked_kind: blockedKind,
277
+ failure_cause: failureCause,
270
278
  truth_status: truth,
271
279
  intent_label: intentLabel,
272
280
  tool_intent: intentLabel,
273
- next_action: shortText(input.next_action || (hasBlockerSignal ? 'resolve the blocker before claiming this loop complete' : 'record the next smallest useful action')),
281
+ next_action: shortText(input.next_action || (uncoveredRequirements.length ? `cover requirement before claiming complete: ${uncoveredRequirements[0]}` : hasBlockerSignal ? 'resolve the blocker before claiming this loop complete' : 'record the next smallest useful action')),
274
282
  safe_retry: shortText(input.safe_retry || (hasBlockerSignal ? 'retry only after the blocker is resolved and new evidence is recorded' : 'not required')),
283
+ recovery_hint: recoveryHint,
275
284
  fix_first_items: asList(input.fix_first_items || input.fix_first_item),
276
285
  remaining_tasks: asList(input.remaining_tasks || input.remaining_task),
277
286
  recommended_direction: shortText(input.recommended_direction || input.direction),
@@ -282,6 +291,7 @@ export function buildLoopReport(input = {}) {
282
291
  owner_scope: asList(input.owner_scope || input.scope),
283
292
  scope_owner: normalizeOwnerRoute(input.scope_owner || input.owner),
284
293
  side_effects: asList(input.side_effects || input.side_effect),
294
+ avoidance_note: avoidanceNote,
285
295
  study_note: studyNote
286
296
  };
287
297
  }
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "yam-flow",
3
- "version": "1.9.1",
3
+ "version": "2.1.0",
4
4
  "description": "Progressive proof-first agent flow: start fast, deepen deliberately, stay honest by design.",
5
5
  "type": "module",
6
6
  "author": "0kim0bos",
@@ -4,10 +4,10 @@ Every `yam` route should end with a compact handoff that helps the next run avoi
4
4
 
5
5
  ## Required Closing Check
6
6
 
7
- Include these when they are useful and keep them short:
7
+ Always keep final reports short. Include these when they apply:
8
8
 
9
9
  - What changed or what was found.
10
- - Change insight for non-specialists: what the touched code does, how it changed, and why it matters.
10
+ - 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.
11
11
  - What verification ran.
12
12
  - What was not checked.
13
13
  - Truth status, when verification or runtime claims matter.
@@ -16,7 +16,7 @@ Include these when they are useful and keep them short:
16
16
  - Context pressure or cleanup findings when they could affect the next run.
17
17
  - Publish blocker evidence when npm/release work fails.
18
18
  - Structured diagnostic next action, when a check found a concrete next step.
19
- - 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.
19
+ - 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.
20
20
  - Remaining tasks.
21
21
  - Fix-first items before planned tasks.
22
22
  - Recommended direction and why that next step matters when the handoff would otherwise be ambiguous.
@@ -58,15 +58,19 @@ Examples:
58
58
 
59
59
  ## Study Note
60
60
 
61
- Use this when implementation changed code or fixed an error and the user would benefit from learning:
61
+ Use this whenever implementation changed code or any project artifact changed:
62
62
 
63
- - What code had the issue.
64
- - What role that code plays.
65
- - How the issue showed up.
66
- - What changed.
67
- - Why the change matters.
63
+ - What code or artifact changed.
64
+ - What role that code or artifact plays in the project.
65
+ - What was wrong, missing, unclear, or risky.
66
+ - What changed and what behavior the change should produce.
67
+ - One small syntax, API, schema, or structure insight for a non-specialist.
68
+ - What was verified, or why verification is partial/skipped/blocked.
69
+ - What remains uncertain.
68
70
 
69
- Keep it short. If the information is not known, say so instead of inventing it.
71
+ 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.
72
+
73
+ Use `references/study-note.md`.
70
74
 
71
75
  ## Handoff Direction
72
76
 
@@ -77,11 +81,13 @@ Use this when the next run needs a clear starting point:
77
81
  - Recommended direction.
78
82
  - Why this next step matters.
79
83
  - What is blocked, and by what.
84
+ - Covered and uncovered requirements when the next run could otherwise overclaim completion.
80
85
  - Evidence level or stamp when the handoff relies on a specific command, file, or report.
81
- - Blocker kind and safe retry when the next run should not blindly repeat the same action.
86
+ - Blocker kind, failure cause, recovery hint, and safe retry when the next run should not blindly repeat the same action.
87
+ - Avoidance note when a repeated mistake should be easy to spot; durable memory still uses explicit `yam memory add`.
82
88
  - Owner route, scope owner, and side effects when more than one person or route may continue the work.
83
89
 
84
- `yam loop report` can record this as a handoff artifact with `fix_first_items`, `remaining_tasks`, `recommended_direction`, `implementation_notes`, `why_this_next`, `blocked_by`, `blocked_kind`, `safe_retry`, `evidence_level`, `evidence_stamp`, `owner_route`, `owner_scope`, `scope_owner`, and `side_effects`.
90
+ `yam loop report` can record this as a handoff artifact with `fix_first_items`, `remaining_tasks`, `recommended_direction`, `implementation_notes`, `why_this_next`, `blocked_by`, `covered_requirements`, `uncovered_requirements`, `blocked_kind`, `failure_cause`, `recovery_hint`, `safe_retry`, `evidence_level`, `evidence_stamp`, `owner_route`, `owner_scope`, `scope_owner`, `side_effects`, and `avoidance_note`.
85
91
 
86
92
  ## Route Weight
87
93
 
@@ -35,6 +35,19 @@ Verification: not run; change was limited to copy/CSS and inspected locally.
35
35
 
36
36
  For larger work, include proof summary and residual risk.
37
37
 
38
+ Use the L0-L5 Verification Ladder:
39
+
40
+ - L0 stated.
41
+ - L1 inspected.
42
+ - L2 local check.
43
+ - L3 integrated.
44
+ - L4 release/runtime/visual proof.
45
+ - L5 bounded deep.
46
+
47
+ Escalate when the claim touches public release, UI done, auth, payment, DB, runtime, deployment, broad refactor, security, high learning value, or explicit user intent.
48
+
49
+ 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.
50
+
38
51
  ## Runtime Guard
39
52
 
40
53
  Runtime work needs stronger evidence because long-running processes can create false success:
@@ -0,0 +1,53 @@
1
+ # Study Note
2
+
3
+ Study Note is required whenever code, config, release metadata, documentation, or project artifacts changed, even if no yam skill was explicitly invoked.
4
+
5
+ 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.
6
+
7
+ ## Final Report Shape
8
+
9
+ 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`.
10
+
11
+ Keep the default note short: 4-7 lines for ordinary work, longer only for `$deep`, `$mission`, release, DB, runtime, or learning-heavy work.
12
+
13
+ Include:
14
+
15
+ - Touched code/artifact: the file, function, component, config, or artifact that changed.
16
+ - Code/artifact role: what that code or artifact does in the project.
17
+ - Problem meaning: what was wrong, missing, unclear, or risky, and how the symptom appeared.
18
+ - Change meaning: what changed and what behavior the change should produce.
19
+ - Syntax or structure insight: one small language, API, schema, or structure insight for a non-specialist.
20
+ - Verification note: what was checked, or why verification is partial/skipped/blocked.
21
+ - Limits: what is not known; do not invent missing cause, behavior, or verification.
22
+
23
+ ## Compact Example
24
+
25
+ ```text
26
+ Study Note:
27
+ - Touched code: `buildLoopReport`, the function that turns loop inputs into report JSON.
28
+ - Code role: it decides whether a loop can honestly say it is verified, partial, or blocked.
29
+ - Problem meaning: a report could include unfinished requirements without making the completion risk obvious.
30
+ - Change meaning: `uncovered_requirements` now lowers the truth status to blocked and points the next action at the missing requirement.
31
+ - Syntax/structure: the code uses an array length check plus a conditional default to choose safer report fields.
32
+ - Verification: typecheck and CLI smoke covered the JSON shape.
33
+ - Limits: this does not infer requirements from prose; the agent/user still has to provide them.
34
+ ```
35
+
36
+ ## When Nothing Changed
37
+
38
+ 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.
39
+
40
+ ## Tone
41
+
42
+ - Use plain language before implementation jargon.
43
+ - Explain the code's responsibility before explaining the patch.
44
+ - Prefer one practical syntax or structure insight over broad teaching.
45
+ - Tie the note to evidence. If no check ran, say so.
46
+ - Keep remaining tasks separate from Study Note.
47
+
48
+ ## What To Avoid
49
+
50
+ - Do not guess root cause when it was not verified.
51
+ - Do not over-explain common syntax when it distracts from the touched code.
52
+ - Do not turn every final report into a long lesson.
53
+ - Do not claim the user learned something; just leave a useful learning path.
@@ -13,7 +13,8 @@ Every route carries a basic contract:
13
13
  - use context packs or memory before broad re-reading
14
14
  - verify only what was actually checked
15
15
  - report remaining tasks and fix-first issues when useful
16
- - explain what changed in plain language when code or behavior changes
16
+ - include a Study Note when code, config, release metadata, documentation, or project artifacts changed
17
+ - explain what changed, what role it has, what behavior is expected, and one useful syntax or structure insight in plain language
17
18
  - treat security as the first project lens
18
19
  - preserve source boundaries when outside references shaped the judgment
19
20
 
@@ -26,6 +27,8 @@ Then depth increases by route:
26
27
  - `$deep`: prove risky single-agent work with stronger runtime/tool evidence.
27
28
  - `$mission`: coordinate real subagents/team lanes with cross-verification.
28
29
 
30
+ 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.
31
+
29
32
  ## Surfaces To Wrap
30
33
 
31
34
  - Local CLI/app readiness.
@@ -94,6 +97,8 @@ On demand:
94
97
 
95
98
  - What the touched code or artifact is responsible for.
96
99
  - What changed in behavior, contract, UI, or safety posture.
100
+ - What syntax, schema, or structure insight helps a non-specialist understand the change.
101
+ - What verification level supports the claim.
97
102
  - Why the change matters to the product or user.
98
103
  - What remains uncertain or unverified.
99
104
  - What should be fixed first before the next planned task.
@@ -1,53 +1,158 @@
1
- # Verification Levels
1
+ # Verification Ladder
2
2
 
3
- ## Level 0: Read/Inspect
3
+ `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.
4
4
 
5
- For copy, spacing, small CSS, docs, or no-runtime changes.
5
+ Use the smallest level that honestly supports the claim, then escalate deliberately.
6
+
7
+ ## L0: Stated
8
+
9
+ Explanation only. No code or artifact was inspected deeply enough to support an implementation claim.
10
+
11
+ Use for:
12
+
13
+ - Pure Q&A.
14
+ - Early plan or hypothesis.
15
+ - Scout recommendation before implementation.
16
+
17
+ Report:
18
+
19
+ - Truth status: `assumed` or `skipped`.
20
+ - Say no verification ran.
21
+
22
+ ## L1: Inspected
23
+
24
+ Relevant file, snippet, error, screenshot, or project context was read.
25
+
26
+ Use for:
27
+
28
+ - Tiny docs/copy/config edits.
29
+ - Local explanation based on source reading.
30
+ - First pass on a small bug.
6
31
 
7
32
  Expected:
8
33
 
9
- - Re-read the changed file or relevant snippet.
34
+ - Re-read the changed snippet.
10
35
  - Check local project fit.
11
- - Report that no command was run.
36
+ - Report that no command ran if none did.
12
37
 
13
- ## Level 1: One Relevant Check
38
+ Truth cap:
14
39
 
15
- For small JS/TS/component changes.
40
+ - Usually `partial` or `assumed`, not `verified`.
41
+
42
+ ## L2: Local Check
43
+
44
+ One focused local check supports the claim.
45
+
46
+ Use for:
47
+
48
+ - Small TS/JS/app logic changes.
49
+ - Narrow bug fixes.
50
+ - Focused build/type/lint/test failures.
16
51
 
17
52
  Examples:
18
53
 
19
- - One focused test.
20
54
  - Typecheck.
21
55
  - Lint for touched area.
56
+ - One focused test.
57
+ - Small CLI smoke for the touched command.
58
+
59
+ Truth cap:
60
+
61
+ - `verified` only for the checked surface.
62
+
63
+ ## L3: Integrated
22
64
 
23
- ## Level 2: Focused Confidence
65
+ The change was checked through a broader local workflow or user-facing path.
24
66
 
25
- For feature-sized work.
67
+ Use for:
68
+
69
+ - Feature-sized work.
70
+ - Package-facing CLI changes.
71
+ - UI changes with visible behavior.
72
+ - Changes that affect multiple files or flows.
26
73
 
27
74
  Examples:
28
75
 
29
- - Typecheck plus related test.
30
- - Build if no narrower test exists.
76
+ - Build.
77
+ - CLI smoke.
78
+ - Relevant workflow command.
79
+ - Browser check or screenshot.
80
+ - UI state/responsive check.
31
81
 
32
- ## Level 3: UI Confidence
82
+ Truth cap:
33
83
 
34
- For visible UI changes.
84
+ - `verified` for the exercised workflow.
85
+ - `partial` when important states, devices, or integrations remain untested.
35
86
 
36
- Expected when feasible:
87
+ ## L4: Release / Runtime / Visual Proof
37
88
 
38
- - Desktop screenshot or browser check.
39
- - Mobile viewport check.
40
- - Check overflow, alignment, contrast, density, and core states.
89
+ Proof artifact or runtime/visual/release evidence supports the claim.
41
90
 
42
- ## Level 4: Deep Confidence
91
+ Use for:
43
92
 
44
- For auth, payment, DB, migration, release, broad refactor, or user-requested deep verification.
93
+ - Public release readiness.
94
+ - Runtime process claims.
95
+ - Cleanup claims.
96
+ - Browser or screenshot visual verification.
97
+ - Auth/payment/DB/deployment/security-sensitive changes.
45
98
 
46
99
  Examples:
47
100
 
48
- - Build.
49
- - Test suite or relevant suites.
50
- - Browser QA.
51
- - Security check.
52
- - Proof summary.
101
+ - `yam release report --json`.
102
+ - Runtime evidence with process, port, URL, or cleanup observation.
103
+ - Ueye visual report with screenshot/provenance.
104
+ - DB/security readiness report.
105
+ - Readiness receipt or proof bundle.
106
+
107
+ Truth cap:
108
+
109
+ - `proven` only when runtime/process evidence exists.
110
+ - `verified` only when the relevant check actually passed.
111
+ - `blocked` when auth/tool/runtime evidence is required but unavailable.
112
+
113
+ ## L5: Bounded Deep
114
+
115
+ Multiple relevant checks are combined, with a stop condition, skipped checks, residual risk, and handoff.
116
+
117
+ Use for:
118
+
119
+ - Broad refactors.
120
+ - Release candidates.
121
+ - Risky auth/payment/DB/runtime/deployment work.
122
+ - User-requested deep verification.
123
+ - Work with high learning value or high false-completion cost.
124
+
125
+ Expected:
126
+
127
+ - Define acceptance criteria.
128
+ - Run the relevant set of checks, not every possible check.
129
+ - Record proof summary or proof bundle lite.
130
+ - List skipped checks and why.
131
+ - List residual risks and remaining tasks.
132
+
133
+ Stop condition:
134
+
135
+ - 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.
136
+ - Stop earlier when the same blocker repeats, a required tool/auth/runtime is unavailable, or a user decision is needed.
137
+ - Do not keep retrying the same failure. Classify `failure_cause`, give `recovery_hint`, and hand off.
138
+
139
+ ## Route Defaults
140
+
141
+ - `$question`: L0-L1.
142
+ - `$scout`: L0-L1 for judgment; source-backed but not implementation verification.
143
+ - `$quick`: L1-L2 by default; L3 only when the claim needs it.
144
+ - `$ueye`: L1-L3 for ordinary UI work; L4 when claiming visual done.
145
+ - `$deep`: L3-L5 when risk or user intent calls for strong verification.
146
+ - `$mission`: L4-L5 when real subagents/team lanes are used, with cross-verification.
147
+
148
+ ## Completion Claim Rule
149
+
150
+ Completion claims require evidence at or above the level implied by the claim:
151
+
152
+ - Code changed: at least L1, preferably L2.
153
+ - User-facing behavior changed: L2-L3.
154
+ - UI done claim: L3-L4 with visual evidence when feasible.
155
+ - Runtime/cleanup claim: L4.
156
+ - Release/auth/DB/security claim: L4-L5.
53
157
 
158
+ If the evidence level is lower than the claim, lower the truth status and report the gap.
@@ -43,7 +43,7 @@ Use for:
43
43
 
44
44
  ## Verification
45
45
 
46
- Use Level 4 from `references/verification-levels.md`.
46
+ Use L3-L5 from `references/verification-levels.md`; pick the smallest bounded set that honestly supports the claim.
47
47
  Use `references/token-economy.md`; wider context is allowed only when tied to the risk surface.
48
48
  Use `references/context-reuse.md`; update stale project packs narrowly when needed.
49
49
  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
52
52
  Use `references/current-docs.md` when SDK/API/cloud-service behavior may be current or version-sensitive.
53
53
  Use `references/trust-kernel.md` when the task asks how yam prevents false completion or fake real proof claims.
54
54
  Use `references/honest-completion.md`; do not overclaim verification, runtime, cleanup, or visual proof.
55
+ Use `references/study-note.md` when any code, config, docs, release metadata, or project artifact changed.
55
56
  Use `references/final-report.md` to close with remaining tasks and fix-first items when useful.
56
57
  Use `references/token-budget-reporter.md` when a run needs measured budget feedback.
57
58
 
@@ -65,12 +66,18 @@ Deep verification may include:
65
66
  - Before/after screenshot.
66
67
  - Risk-specific manual inspection.
67
68
 
69
+ Stop condition:
70
+
71
+ - 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.
72
+ - Stop earlier when the same blocker repeats, a required tool/auth/runtime is unavailable, or a user decision is needed.
73
+ - Do not keep retrying the same failure; classify the cause, give a recovery hint, and hand off.
74
+
68
75
  ## Final Response
69
76
 
70
77
  Include:
71
78
 
72
79
  - What was changed or reviewed.
73
- - 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.
80
+ - 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.
74
81
  - Evidence gathered.
75
82
  - Truth status.
76
83
  - Blockers or remaining risk.
@@ -58,6 +58,12 @@ Do not use for:
58
58
  12. Confirm cleanup or explicitly report intentionally running processes.
59
59
  13. Produce final proof summary, truth status, remaining tasks, and fix-first items.
60
60
 
61
+ Mission stop condition:
62
+
63
+ - 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.
64
+ - Stop earlier when the same blocker repeats, a required tool/auth/runtime is unavailable, or a user decision is needed.
65
+ - Do not keep retrying the same failure; classify the cause, give a recovery hint, and hand off.
66
+
61
67
  ## Proof Summary
62
68
 
63
69
  Include:
@@ -79,7 +85,9 @@ Use `references/runtime-orchestration.md` only when runtime evidence is needed.
79
85
  Use `references/doctor-scan.md` before final mission completion.
80
86
  Use `references/db-supabase-safety-lite.md` for destructive DB/Supabase, migration, production-write, or RLS/policy lanes.
81
87
  Use `references/current-docs.md` when any lane depends on current SDK/API/cloud-service behavior.
88
+ Use `references/verification-levels.md` for L4-L5 mission proof boundaries.
82
89
  Use `references/honest-completion.md`; do not overclaim.
90
+ Use `references/study-note.md` for every lane that changes code, config, docs, release metadata, or project artifacts.
83
91
  Use `references/final-report.md` to close with remaining tasks and fix-first items.
84
92
  Use `references/token-budget-reporter.md` when budget drift matters.
85
93
 
@@ -102,7 +110,7 @@ Report:
102
110
 
103
111
  - What the mission changed.
104
112
  - Role/cross-verification summary.
105
- - 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.
113
+ - 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.
106
114
  - Evidence gathered.
107
115
  - Truth status.
108
116
  - Cleanup status.
@@ -58,16 +58,19 @@ Scan lane:
58
58
 
59
59
  ## Verification
60
60
 
61
- - Copy/CSS/docs: Level 0 is often enough after re-reading the changed snippet.
61
+ - Copy/CSS/docs: L1 is often enough after re-reading the changed snippet.
62
62
  - TS/JS or app logic: prefer typecheck, related test, lint, or build in that order when available.
63
63
  - Build-fix: use a compact PASS/FAIL matrix for command results.
64
64
  - If verification is skipped, partial, blocked, or assumed, say that plainly.
65
+ - Escalate beyond L2 only when the changed behavior, user-facing impact, or risk surface needs it.
65
66
 
66
67
  Use `references/quick.md` for the merged fast/build rules.
68
+ Use `references/verification-levels.md` for the L0-L5 ladder.
67
69
  Use `references/truth-matrix.md` for truth labels.
68
70
  Use `references/db-supabase-safety-lite.md` when a command or prompt contains DB/Supabase mutation signals.
69
71
  Use `references/token-economy.md` to keep context small.
70
72
  Use `references/context-reuse.md` before broad project reading.
73
+ Use `references/study-note.md` when any code, config, docs, or project artifact changed.
71
74
  Use `references/final-report.md` to close with remaining tasks and fix-first items when useful.
72
75
  Use `references/token-budget-reporter.md` when a run needs measured budget feedback.
73
76
 
@@ -76,7 +79,7 @@ Use `references/token-budget-reporter.md` when a run needs measured budget feedb
76
79
  Keep it compact:
77
80
 
78
81
  - What changed or what the scan found.
79
- - 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.
82
+ - 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.
80
83
  - What was checked.
81
84
  - What was skipped, blocked, or still risky.
82
85
  - 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.
@@ -43,6 +43,7 @@ Do not use for:
43
43
  - 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.
44
44
  - Ueye owns the design completion gate. Do not rely on a separate code-risk route to catch sloppy visual completion.
45
45
  - Draft or needs-polish work may stay fast; a `done` claim requires recorded design gate evidence.
46
+ - Use the Verification Ladder: ordinary UI implementation can stay L1-L3, but a visual `done` claim needs L3-L4 evidence when feasible.
46
47
  - 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.
47
48
 
48
49
  ## Workflow
@@ -145,6 +146,8 @@ Use these artifacts for reference-led implementation or serious visual review. K
145
146
  ## Design Checks
146
147
 
147
148
  Use `references/ueye.md` and `references/ui-quality.md`.
149
+ Use `references/verification-levels.md` for visual proof levels and done-claim truth caps.
150
+ Use `references/study-note.md` when UI code, design docs, config, or project artifacts changed.
148
151
  Always consider:
149
152
 
150
153
  - Direction fit.
@@ -170,6 +173,6 @@ Report:
170
173
  - Review continuity/comparison result when this continues a prior Ueye run.
171
174
  - P0-P3 issues or confirmation that no blockers were found.
172
175
  - States/viewports checked.
173
- - 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.
176
+ - 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.
174
177
  - Truth status and visual verification cap.
175
178
  - 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 CHANGED
@@ -346,6 +346,7 @@ async function verify({ quiet = false } = {}) {
346
346
  'token-economy.md',
347
347
  'context-reuse.md',
348
348
  'markdown-management.md',
349
+ 'study-note.md',
349
350
  'final-report.md',
350
351
  'token-budget-reporter.md',
351
352
  'memory.md'
@@ -1575,6 +1576,7 @@ function runReleaseReport() {
1575
1576
  const publishReadiness = releasePublishReadiness(checks, provenance, tarball, publishBlockerEvidence);
1576
1577
  const nextActions = releaseNextActions(checks, provenance, tarball, publishBlockerEvidence, publishReadiness);
1577
1578
  const ok = failed.length === 0 && publishReadiness.status === 'ready';
1579
+ const readinessReceipt = releaseReadinessReceipt(provenance, freshness, tarball, publishReadiness, ok);
1578
1580
  return {
1579
1581
  schema: 'yam.release-report.v1',
1580
1582
  generated_at: startedAt,
@@ -1588,12 +1590,55 @@ function runReleaseReport() {
1588
1590
  tarball,
1589
1591
  freshness,
1590
1592
  publish_readiness: publishReadiness,
1593
+ readiness_receipt: readinessReceipt,
1591
1594
  study_note: releaseStudyNote(publishReadiness, publishBlockerEvidence),
1592
1595
  publishBlockerEvidence,
1593
1596
  next_actions: nextActions
1594
1597
  };
1595
1598
  }
1596
1599
 
1600
+ function releaseReadinessReceipt(provenance: AnyRecord = {}, freshness: AnyRecord = {}, tarball: AnyRecord = {}, publishReadiness: AnyRecord = {}, ok = false) {
1601
+ return {
1602
+ schema: 'yam.release-readiness-receipt.v1',
1603
+ generated_at: new Date().toISOString(),
1604
+ package_name: PACKAGE_JSON.name,
1605
+ local_version: VERSION,
1606
+ registry: {
1607
+ url: String(publishReadiness.registry?.url || ''),
1608
+ latest_version: String(publishReadiness.registry?.latest_version || ''),
1609
+ version_status: String(publishReadiness.registry?.version_status || 'not_verified'),
1610
+ truth_status: publishReadiness.registry?.truth_status || 'partial'
1611
+ },
1612
+ auth: {
1613
+ command: 'npm whoami',
1614
+ status: String(publishReadiness.auth?.status || 'not_verified'),
1615
+ account: publishReadiness.auth?.status === 'authenticated' ? 'observed_redacted' : '',
1616
+ truth_status: publishReadiness.auth?.truth_status || 'partial'
1617
+ },
1618
+ git: {
1619
+ commit: String(provenance.git_commit || ''),
1620
+ dirty: Boolean(provenance.git_dirty),
1621
+ dirty_lines_observed: Array.isArray(provenance.git_status_lines) ? provenance.git_status_lines.length : 0,
1622
+ truth_status: provenance.truth_status || 'partial'
1623
+ },
1624
+ checks: {
1625
+ dist: freshness.dist || 'not-verified',
1626
+ package_boundary: freshness.package_boundary || 'not-verified',
1627
+ cli_smoke: freshness.cli_smoke || 'not-verified',
1628
+ tarball: tarball.status === 'checked' ? 'checked' : 'not-verified'
1629
+ },
1630
+ tarball: {
1631
+ status: String(tarball.status || 'not-verified'),
1632
+ name: String(tarball.tarball_name || ''),
1633
+ integrity_present: Boolean(tarball.integrity),
1634
+ shasum_present: Boolean(tarball.shasum),
1635
+ truth_status: tarball.truth_status || 'partial'
1636
+ },
1637
+ publish_attempted: false,
1638
+ truth_status: ok ? 'verified' : 'blocked'
1639
+ };
1640
+ }
1641
+
1597
1642
  function releaseProvenance(checks = []) {
1598
1643
  const gitCommit = runReadOnlyCommand('git', ['rev-parse', '--short', 'HEAD']);
1599
1644
  const gitStatus = runReadOnlyCommand('git', ['status', '--short']);
@@ -1977,13 +2022,13 @@ function loopUsage() {
1977
2022
  Read-only loop artifact helpers. A loop report records intent, stages, evidence, blockers, next action, handoff fields, and a short study note. It does not run agents, start processes, publish packages, or write files.
1978
2023
 
1979
2024
  Usage:
1980
- yam loop report [--route route] [--intent text] [--loop-kind harness|release|ueye|scout|deep|mission] [--stage id:status:note] [--evidence text] [--evidence-level none|fixture|smoke|local|real] [--evidence-stamp text] [--source-digest text] [--blocked text] [--blocked-kind text] [--safe-retry text] [--fix-first-item text] [--remaining-task text] [--recommended-direction text] [--implementation-note text] [--why-this-next text] [--blocked-by text] [--owner-route route] [--owner-scope text] [--scope-owner text] [--side-effect text] [--truth status] [--intent-label read_only|write|destructive|runtime|visual|publish] [--issue-code text] [--issue-role text] [--issue-symptom text] [--changed-code text] [--changed-role text] [--change-summary text] [--why-important text] [--learning-note text] [--json]
2025
+ yam loop report [--route route] [--intent text] [--loop-kind harness|release|ueye|scout|deep|mission] [--stage id:status:note] [--evidence text] [--evidence-level none|fixture|smoke|local|real] [--evidence-stamp text] [--source-digest text] [--covered-requirement text] [--uncovered-requirement text] [--blocked text] [--blocked-kind text] [--failure-cause text] [--safe-retry text] [--recovery-hint text] [--fix-first-item text] [--remaining-task text] [--recommended-direction text] [--implementation-note text] [--why-this-next text] [--blocked-by text] [--owner-route route] [--owner-scope text] [--scope-owner text] [--side-effect text] [--avoidance-note text] [--truth status] [--intent-label read_only|write|destructive|runtime|visual|publish] [--issue-code text] [--issue-role text] [--issue-symptom text] [--changed-code text] [--changed-role text] [--change-summary text] [--why-important text] [--learning-note text] [--json]
1981
2026
  `);
1982
2027
  }
1983
2028
 
1984
2029
  async function loopReport(args = []) {
1985
2030
  if (args[0] === 'help' || args[0] === '--help' || args[0] === '-h') return loopUsage();
1986
- const flags = parseSimpleFlags(args, new Set(['route', 'intent', 'loop-kind', 'stage', 'stage-convention', 'evidence', 'evidence-level', 'evidence-stamp', 'source-digest', 'blocked', 'blocker', 'blocked-kind', 'next-action', 'safe-retry', 'fix-first-item', 'remaining-task', 'recommended-direction', 'direction', 'implementation-note', 'why-this-next', 'blocked-by', 'owner-route', 'owner-scope', 'scope-owner', 'owner', 'scope', 'side-effect', 'truth', 'intent-label', 'tool-intent', 'issue-code', 'issue-role', 'issue-symptom', 'changed-code', 'changed-role', 'change-summary', 'why-important', 'learning-note', 'json']));
2031
+ const flags = parseSimpleFlags(args, new Set(['route', 'intent', 'loop-kind', 'stage', 'stage-convention', 'evidence', 'evidence-level', 'evidence-stamp', 'source-digest', 'covered-requirement', 'uncovered-requirement', 'blocked', 'blocker', 'blocked-kind', 'failure-cause', 'next-action', 'safe-retry', 'recovery-hint', 'fix-first-item', 'remaining-task', 'recommended-direction', 'direction', 'implementation-note', 'why-this-next', 'blocked-by', 'owner-route', 'owner-scope', 'scope-owner', 'owner', 'scope', 'side-effect', 'avoidance-note', 'truth', 'intent-label', 'tool-intent', 'issue-code', 'issue-role', 'issue-symptom', 'changed-code', 'changed-role', 'change-summary', 'why-important', 'learning-note', 'json']));
1987
2032
  const blockers = [...arrayFlag(flags.blocked), ...arrayFlag(flags.blocker)];
1988
2033
  const report = buildLoopReport({
1989
2034
  route: normalizeRoute(flags.route) || String(flags.route || ''),
@@ -1995,12 +2040,16 @@ async function loopReport(args = []) {
1995
2040
  evidence_level: normalizeLoopEvidenceLevelFlag(flags.evidence_level),
1996
2041
  evidence_stamp: String(flags.evidence_stamp || ''),
1997
2042
  source_digest: String(flags.source_digest || ''),
2043
+ covered_requirements: arrayFlag(flags.covered_requirement),
2044
+ uncovered_requirements: arrayFlag(flags.uncovered_requirement),
1998
2045
  blockers,
1999
2046
  blocked_kind: String(flags.blocked_kind || ''),
2047
+ failure_cause: String(flags.failure_cause || ''),
2000
2048
  truth_status: isTruthStatus(flags.truth) ? flags.truth : undefined,
2001
2049
  intent_label: normalizeToolIntent(flags.intent_label || flags.tool_intent || 'read_only'),
2002
2050
  next_action: String(flags.next_action || ''),
2003
2051
  safe_retry: String(flags.safe_retry || ''),
2052
+ recovery_hint: String(flags.recovery_hint || ''),
2004
2053
  fix_first_items: arrayFlag(flags.fix_first_item),
2005
2054
  remaining_tasks: arrayFlag(flags.remaining_task),
2006
2055
  recommended_direction: String(flags.recommended_direction || flags.direction || ''),
@@ -2011,6 +2060,7 @@ async function loopReport(args = []) {
2011
2060
  owner_scope: [...arrayFlag(flags.owner_scope), ...arrayFlag(flags.scope)],
2012
2061
  scope_owner: String(flags.scope_owner || flags.owner || ''),
2013
2062
  side_effects: arrayFlag(flags.side_effect),
2063
+ avoidance_note: String(flags.avoidance_note || ''),
2014
2064
  issue_code: String(flags.issue_code || ''),
2015
2065
  issue_role: String(flags.issue_role || ''),
2016
2066
  issue_symptom: String(flags.issue_symptom || ''),
@@ -3727,7 +3777,7 @@ function printDetection(result) {
3727
3777
  }
3728
3778
  console.log('');
3729
3779
  console.log('Smallest useful checks:');
3730
- console.log(`- $quick: ${result.commands.typecheck || result.commands.lint || result.commands.test || result.commands.build || 'Level 0 read/inspect; no command detected'}`);
3780
+ console.log(`- $quick: ${result.commands.typecheck || result.commands.lint || result.commands.test || result.commands.build || 'L1 inspected; no command detected'}`);
3731
3781
  console.log(`- $ueye: ${result.commands.typecheck || result.commands.build || 'Browser/screenshot check; no command detected'}`);
3732
3782
  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}`}`);
3733
3783
  if (result.frameworkChecklist?.detected) {
@@ -189,13 +189,17 @@ export interface LoopReport {
189
189
  evidence_level: LoopEvidenceLevel;
190
190
  evidence_stamp: string;
191
191
  source_digest: string;
192
+ covered_requirements: string[];
193
+ uncovered_requirements: string[];
192
194
  blockers: string[];
193
195
  blocked_kind: string;
196
+ failure_cause: string;
194
197
  truth_status: TruthStatus;
195
198
  intent_label: ToolIntent;
196
199
  tool_intent: ToolIntent;
197
200
  next_action: string;
198
201
  safe_retry: string;
202
+ recovery_hint: string;
199
203
  fix_first_items: string[];
200
204
  remaining_tasks: string[];
201
205
  recommended_direction: string;
@@ -206,6 +210,7 @@ export interface LoopReport {
206
210
  owner_scope: string[];
207
211
  scope_owner: string;
208
212
  side_effects: string[];
213
+ avoidance_note: string;
209
214
  study_note: StudyNote;
210
215
  }
211
216
 
@@ -550,13 +555,18 @@ export function buildLoopReport(input: Partial<LoopReport> & Record<string, unkn
550
555
  ? input.stages.map((stage) => buildLoopStage(stage))
551
556
  : [];
552
557
  const evidence = asList(input.evidence);
558
+ const coveredRequirements = asList(input.covered_requirements || input.covered_requirement);
559
+ const uncoveredRequirements = asList(input.uncovered_requirements || input.uncovered_requirement);
553
560
  const blockers = asList(input.blockers || input.blocked);
554
561
  const blockedBy = asList(input.blocked_by);
555
- const blockedKind = shortText(input.blocked_kind || (blockers.length || blockedBy.length ? 'evidence_missing' : ''));
562
+ const blockedKind = shortText(input.blocked_kind || (uncoveredRequirements.length ? 'requirement_uncovered' : blockers.length || blockedBy.length ? 'evidence_missing' : ''));
563
+ const failureCause = shortText(input.failure_cause);
564
+ const recoveryHint = shortText(input.recovery_hint);
565
+ const avoidanceNote = shortText(input.avoidance_note);
556
566
  const evidenceStamp = shortText(input.evidence_stamp || input.source_digest, 320);
557
567
  const sourceDigest = shortText(input.source_digest || input.evidence_stamp, 320);
558
568
  const hasBlockedStage = stages.some((stage) => stage.status === 'blocked' || stage.status === 'failed');
559
- const hasBlockerSignal = Boolean(blockers.length || blockedBy.length || blockedKind);
569
+ const hasBlockerSignal = Boolean(blockers.length || blockedBy.length || blockedKind || uncoveredRequirements.length);
560
570
  const requestedTruth = isTruthStatus(input.truth_status) ? input.truth_status : '';
561
571
  const derivedTruth: TruthStatus = hasBlockerSignal || hasBlockedStage ? 'blocked'
562
572
  : evidence.length && stages.some((stage) => stage.status === 'passed') ? 'verified'
@@ -579,13 +589,17 @@ export function buildLoopReport(input: Partial<LoopReport> & Record<string, unkn
579
589
  evidence_level: normalizeLoopEvidenceLevel(input.evidence_level),
580
590
  evidence_stamp: evidenceStamp,
581
591
  source_digest: sourceDigest,
592
+ covered_requirements: coveredRequirements,
593
+ uncovered_requirements: uncoveredRequirements,
582
594
  blockers,
583
595
  blocked_kind: blockedKind,
596
+ failure_cause: failureCause,
584
597
  truth_status: truth,
585
598
  intent_label: intentLabel,
586
599
  tool_intent: intentLabel,
587
- next_action: shortText(input.next_action || (hasBlockerSignal ? 'resolve the blocker before claiming this loop complete' : 'record the next smallest useful action')),
600
+ next_action: shortText(input.next_action || (uncoveredRequirements.length ? `cover requirement before claiming complete: ${uncoveredRequirements[0]}` : hasBlockerSignal ? 'resolve the blocker before claiming this loop complete' : 'record the next smallest useful action')),
588
601
  safe_retry: shortText(input.safe_retry || (hasBlockerSignal ? 'retry only after the blocker is resolved and new evidence is recorded' : 'not required')),
602
+ recovery_hint: recoveryHint,
589
603
  fix_first_items: asList(input.fix_first_items || input.fix_first_item),
590
604
  remaining_tasks: asList(input.remaining_tasks || input.remaining_task),
591
605
  recommended_direction: shortText(input.recommended_direction || input.direction),
@@ -596,6 +610,7 @@ export function buildLoopReport(input: Partial<LoopReport> & Record<string, unkn
596
610
  owner_scope: asList(input.owner_scope || input.scope),
597
611
  scope_owner: normalizeOwnerRoute(input.scope_owner || input.owner),
598
612
  side_effects: asList(input.side_effects || input.side_effect),
613
+ avoidance_note: avoidanceNote,
599
614
  study_note: studyNote
600
615
  };
601
616
  }
@@ -44,6 +44,8 @@
44
44
  - UI changes:
45
45
  - Feature changes:
46
46
  - Risky changes:
47
+ - Verification ladder: L0 stated, L1 inspected, L2 local check, L3 integrated, L4 release/runtime/visual proof, L5 bounded deep.
48
+ - Stop condition for heavy verification:
47
49
  - Public/release changes: scan for external tool names, comparison wording, and attribution wording; remove those hits unless the user explicitly approves keeping them.
48
50
 
49
51
  ## Security Policy
@@ -56,7 +58,8 @@
56
58
 
57
59
  ## Report Policy
58
60
 
59
- - Explain changed code in plain language:
61
+ - Study Note requirement for changed code/config/release metadata/docs/artifacts:
62
+ - Explain touched code or artifact role, changed behavior, one syntax/structure insight, verification, and uncertainty:
60
63
  - Always include remaining tasks or useful improvements:
61
64
  - Preserve source boundaries for research/proof notes:
62
65
 
package/yam.manifest.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "yam",
3
- "version": "1.9.1",
3
+ "version": "2.1.0",
4
4
  "principles": [
5
5
  "Direction before execution.",
6
6
  "Start fast.",
@@ -11,8 +11,10 @@
11
11
  "Token-aware by default.",
12
12
  "Context-reuse first.",
13
13
  "End with remaining tasks and fix-first items.",
14
- "Explain what failed, what changed, and why it matters in short non-specialist language when useful.",
15
- "Use handoff notes for fix-first items, remaining tasks, recommended next direction, blocker kind, safe retry, evidence level, and owner scope when useful."
14
+ "When code, config, release metadata, documentation, or project artifacts changed, include a Study Note even if no yam skill was explicitly invoked.",
15
+ "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.",
16
+ "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.",
17
+ "Use bounded heavy verification for serious claims, with explicit stop conditions instead of endless proof loops."
16
18
  ],
17
19
  "defaultHooks": false,
18
20
  "routes": [