@outerlayer/cli 0.12.0 → 0.14.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@outerlayer/cli",
-  "version": "0.12.0",
+  "version": "0.14.0",
   "description": "OuterLayer CLI — commands: init, connect, doctor, login, logout, sync, daemon (alias: watch), emit, work, runner, hooks, mcp, import, context. Capture and sync coding-agent sessions, and record proof of factory work.",
   "license": "Apache-2.0",
   "author": "Magu Studios, Inc.",

package/skill-pack/maintained/emitting-evidence/SKILL.md

@@ -104,9 +104,15 @@ Then run `outerlayer sync`, and copy the report's deep link from the pull reques
 
 Use `--result fail` when the review left a finding unfixed. Record it once. Outside a build, pass the item's number to `--item`.
 
-## The criteria report
+## The criteria report and the `acceptance-criteria` check
 
-Bind the judge's report on each criterion, an HTML file, with `--for acceptance-criteria`. No check requires it. The item page links it at the top of its Criteria tab for the reviewer. Emit it only when the item has recorded criteria.
+Bind the judge's report on each criterion, an HTML file, with `--for acceptance-criteria`. The item page links it at the top of its Criteria tab for the reviewer. Emit it only when the item has recorded criteria.
+
+Then run `outerlayer sync`, copy the report's deep link from the evidence comment the same way, and record the judge's verdict on the `acceptance-criteria` check that `outerlayer init` writes:
+
+    outerlayer emit acceptance-criteria --item "$OUTERLAYER_WORK" --result pass --link <the report's deep link>
+
+Use `--result pass` only when the judge found every criterion it judged satisfied, and `--result fail` when it found one unmet. When there is no criterion to judge, record nothing: the row reads "not proven", which is true. Skip the emit in a repository with no `.outerlayer/validators/acceptance-criteria.yaml`.
 
 A session never records a pass or fail on an artifact. It emits the artifact, and a person or a check decides.
 

package/skill-pack/shipped.json

@@ -0,0 +1,70 @@
+{
+  "schemaVersion": 1,
+  "files": {
+    ".outerlayer/policy.yaml": [
+      "1d874f1f521a79fc286ed5400c20022921e017f48e60e474015fedc29a1130a2",
+      "78c95632b51600df0cb2e206d843e75789ccba2f80fd8dfab36d16239062b008"
+    ],
+    ".outerlayer/skills/build/SKILL.md": [
+      "5cf9bd75fb1f984f6e6b470d1f1581dc06168abf062448e6f43711fed8f6632a",
+      "6177ea457be0d238659640e6d29807708d60d68533ae3ff93af10fb513139ced",
+      "77cab8b446fb1aa865710f7cb8356c5334301a942f58f9243766bf1acf1377ad",
+      "a6743050c5c387e962ad4264526d9a3c10edf36823e4b6829f200bf79a4e45e7",
+      "b0aa9b6962675f772b67a4390c15b6b0100390983d958c656a826a066399f3d0",
+      "f4e1661c6f87d7ff6d23c6182530fa0a9cb87c4dc3f31e48f2be11f32ebb2c00"
+    ],
+    ".outerlayer/skills/build/references/agent-briefs.md": [
+      "3c875a4f287f574eea954c6daa52b17529cdeba8ec4007d78084d911350d1218",
+      "7c2a651e7c827d8e3fb9df889d3776b552eb02d315db5ace27d2baad78aab6a5"
+    ],
+    ".outerlayer/skills/build/references/criteria-judge.md": [
+      "62db8f6d77f31ca25a9071c05429e0f639f9b2bdd7f7cb04cb14a1b0db509537"
+    ],
+    ".outerlayer/skills/build/references/evidence.md": [
+      "ceff5488bae31198ed4738ae1a230c0119f973ced439dac360eba6e24e1604f4",
+      "f27502610358e436e7ffb61d4fd281289e162f6de6b2c11396f17b2fa63802c9"
+    ],
+    ".outerlayer/skills/build/references/release.md": [
+      "0b0af40c82473cf192f697537ed5a84801a14e79bb11790d72226d7f7f49cca0",
+      "1113259bdf7d8c28edcbdb9b4c83c2f2bd4c5eaf817cf30bf428478ff91694e9",
+      "4687f56bcec766f1926d58a208418f800a1727c073b5e6047b40e3aaac2bd6c9",
+      "81a764eb317fcb4672bedd35e7b9aa68d1c0b73f82fc2dfa03e5a78758db8f14",
+      "985e02b98105b00c356014e003b2d60e9c458c3dcbeef7378274ccb84af031fc"
+    ],
+    ".outerlayer/skills/build/references/review-briefs.md": [
+      "2c8b436795b583a61aa6f98f48611db554f0dd52b27a9ab748a7db5f96526aec"
+    ],
+    ".outerlayer/skills/build/references/review-loop.md": [
+      "155ab732ccf4c25f000853e98a27a3d2f3a022c75979601bb71d86f07983216d",
+      "5f30b56d226b279ec5f65ad73b823e3aeeac0c14f2ee539fb79cf7ba7b2cac6d",
+      "6f93e2ae74d3c02a0d4c14a6b2c805f523d234a8c56789f40a7c7c59700ef277",
+      "9d4d2e5e0307ea8c38cf885cd67d06a939b7fc2bed65f5080ca9610178949d74"
+    ],
+    ".outerlayer/skills/build/scripts/record-criteria.mjs": [
+      "36f19e730bc220fa21622b3bb0a306999f038b8220a0a07a1efe21ec0f748729",
+      "596e9a78e62cbea040a3bf428cd54bf59687e9e89001fad719304f88d03ca2ea",
+      "64de9445087b247b0781a4e6e025ef97b1259ce1c91819bf541decc26b8f8400"
+    ],
+    ".outerlayer/skills/spec/SKILL.md": [
+      "71e81fabf353ad6117c54e061868538bf00066b78c2528f5a8364445d1def02e",
+      "9039ae30d4e836b5c5cfba4a14344e46fd13694ae9e4d88e750abce34dfcd9e6"
+    ],
+    ".outerlayer/skills/writing-specs/SKILL.md": [
+      "a956aac4249118a058c4327c5751472883588720950d4a96f80c7e91f454bef9",
+      "eb8aa95f5e76a46ae9bf340989fb40e470fd750ded791ba80b5f8c5c325513e5"
+    ],
+    ".outerlayer/skills/writing-specs/references/agents-snippet.md": [
+      "fc47325f27cfce406a14ad71009d3687d3720deb572d40936e29fd091ca6c71d"
+    ],
+    ".outerlayer/skills/writing-tests/SKILL.md": [
+      "b00f5970b568159ca0bfbc75c3834938749ad5e2e73a80769d88bbe3c8c26737"
+    ],
+    ".outerlayer/validators/acceptance-criteria.yaml": [
+      "3b2054aa1d4bd9f7441e88eec1a3bdf61b61ad00efa79736e26a5dd601d43910"
+    ],
+    ".outerlayer/validators/code-review.yaml": [
+      "05041976e4d84d6256ed88995ea4fd1566abc6d3a9574863065cf855dcafcf70",
+      "fbdf0baca0064b09e47f5984afc322d582accd142c3377c06622bc6567b0e98c"
+    ]
+  }
+}

package/skill-pack/template/build/SKILL.md

@@ -84,8 +84,9 @@ These bind the orchestrator in every phase. Rule 5 also binds every spawned agen
    "$OUTERLAYER_WORK" --json`. Each thread with `waitingOn` of `agent` holds a
    person's comment. Answer each before the run ends, as the `amend` skill does.
 5. **A session never records a pass or fail on an artifact.** It emits
-   artifacts. A person decides pass or fail. The one result a build records
-   is its own review's verdict, on the `code-review` check.
+   artifacts. A person decides pass or fail. A build records two results,
+   both verdicts of its own agents: its review's, on the `code-review`
+   check, and its criteria judge's, on the `acceptance-criteria` check.
 6. **Observed status only.** Every status claim in the final report (a gate
    result, a CI conclusion, mergeability) quotes command output observed
    after the last change it describes. No quoted output means unknown, never
@@ -125,48 +126,75 @@ Run them in order.
    has not expired, stop and name it.
    Phase 2 finds the issue's criteria. If it finds some, they are the
    definition of done, and each declares a proof form or a test. If it finds
-   none, build from the issue's description. An issue without criteria is
-   built, never sent back. Then no judge runs.
+   none, the build drafts them from the issue's description, and the drafted
+   criteria are the definition of done in the same way. An issue is never
+   sent back for lacking criteria.
    Ask nothing from here until the final report. An agent that needs a ruling
    states its assumption in its report and continues. The final report lists
    every assumption.
 2. **Read the criteria.** Record the issue's criteria on the item, so the
    Criteria tab, the item's status and the judge hold the pull request to one
-   list. Save the issue body to a file and run:
-
-       node .outerlayer/skills/build/scripts/record-criteria.mjs --item "$OUTERLAYER_WORK" --issue-file <body file>
-
-   The script reads two shapes, in this order:
-
-   1. An `## Acceptance criteria` section whose items each start with an id in
-      backticks. The id and the text after it are kept as written. A
-      `(proof: <kind>)` on the line sets `proof`. Otherwise `proof` is `null`.
-   2. A heading or line that reads `Acceptance`, `Acceptance criteria` or
-      `Done when`, in any case, with or without a colon, followed by a bullet
-      list. Each bullet is one criterion. Its text is the bullet's text. Its id
-      is `AC-<item number>-NN`, numbered from `01` in list order. `proof` is
-      `null`. Never infer a proof kind from the words.
-
-   It writes the list to
+   list. Read the whole issue and find its acceptance criteria in whatever
+   form they are written: under a heading of any wording, as a checklist or
+   numbered items, as "done when" prose, with ids or without. There is no
+   fixed shape. Keep each criterion's text exactly as the author wrote it.
+   Never reword one. A criterion you think is wrong becomes a note in the
+   final report, never an edit.
+
+   Write them, in the order the issue lists them, to a file:
+
+       { "criteria": [ { "id": "<the id, if the issue gives one>", "text": "<verbatim>", "proof": null } ] }
+
+   Give `proof` an artifact kind (`video`, `screenshot`, `report`, `log`,
+   `test` or `file`) only when the issue states that proof explicitly, as in
+   `(proof: screenshot)`. Never infer a proof kind from the words. Then run:
+
+       node .outerlayer/skills/build/scripts/record-criteria.mjs --item "$OUTERLAYER_WORK" --criteria-file <file>
+
+   The script keeps the issue's ids only when every criterion carries one
+   that fits the id grammar. Otherwise, a partly numbered list included, it
+   numbers every criterion `AC-<item number>-NN` in order, and the state file
+   says why. The final report says the criteria were numbered and from what.
+   A file the script cannot use exits 2 with the reason. Fix the file and
+   run it again.
+
+   When the issue has no criteria anywhere, draft them from the issue's
+   description. Each is one observable behavior the description asks for, in
+   its words, adding no scope it does not state. Write them to the same kind
+   of file without ids, set `proof` only when the description asks for that
+   proof, and run the script with `--drafted` added. It numbers the draft
+   `AC-<item number>-NN` and records it with `drafted: true`, so the Criteria
+   tab says the build drafted the list.
+
+   The script writes the list to
    `"$(git rev-parse --absolute-git-dir)/build-reports/criteria.json"` and runs
    `outerlayer emit criteria` on it. The gateway decides whether a list may be
    recorded. A 409 means the item already has a recorded list. That list
    stands, and nothing is recorded. No command returns the item's list, so the
-   build cannot read it: it holds the work to the issue's reading of the criteria and says
-   so in the final report. Any other
-   refusal is written to the state file with its message, and the build
-   continues. The script writes the outcome under `criteria` in the state
-   file: `source` (`issue-ids`, `issue-bullets`, `item` or `none`), `recorded`,
-   `count` and `list`. On a 409, `list` is empty, and the issue's reading of the
-   criteria goes under `issueReading`. If neither shape is found, nothing is recorded and the
-   build continues at the small tier, as for any issue without criteria. Change
-   nothing in the issue. A criterion you think is wrong becomes a note in the
-   final report, never an edit. The intake summary names how many criteria were
-   recorded and from which shape, or says that none were found.
-3. **Implement.** Branch `feat/<slug>` from the default branch. Spawn the
-   implementer with the Implementer brief from
+   build cannot read it: it holds the work to its own reading of the criteria
+   and says so in the final report. Any other refusal is written to the state
+   file with its message, and the build continues. The script writes the
+   outcome under `criteria` in the state file: `source` (`issue`, `drafted`,
+   `item`, or `none` when even a draft holds no criterion), `recorded`,
+   `count`, `list` and `numbered`. On a 409, `list` is empty, and the build's
+   reading of the criteria goes under `issueReading`.
+
+   Drafted criteria are tiered, proven and judged like any others. A drafted
+   list stands like any recorded list. A later build's record
+   answers 409 until a person replaces the list with
+   `outerlayer emit criteria`, even after criteria are added to the issue. The
+   final report says the criteria were drafted and how to replace them.
+
+   Change nothing in the issue. The intake summary names how many criteria
+   were recorded, whether they kept the issue's ids or were numbered, and
+   whether they were drafted.
+3. **Implement.** When `OUTERLAYER_BRANCH` is set, as it is in a host's
+   build, work on that branch, checking it out if it is not current, and
+   push only to it: the host refuses a push to any other branch. Otherwise
+   branch `feat/<slug>` from the default branch. Spawn the implementer with the Implementer brief from
    [references/agent-briefs.md](references/agent-briefs.md), the issue, the
-   branch and the instructions-file pointer. The phase ends when the
+   drafted criteria with their ids when the build drafted them, the branch
+   and the instructions-file pointer. The phase ends when the
    repository's own pre-push checks and tests pass on the branch. Review
    never opens on a red branch. A branch that cannot go green escalates.
 4. **Review.** Read [references/review-loop.md](references/review-loop.md) on
@@ -185,12 +213,15 @@ Run them in order.
    on entry and run it. A release agent rebases, gates and pushes. Open the
    pull request as release.md says: a runner build with `outerlayer work open-pr`,
    which links it, and a local session with `gh pr create` and then
-   `outerlayer work pr <number>`. When the issue has criteria, a fresh agent judges them with
+   `outerlayer work pr <number>`. When the build recorded criteria, from the issue or drafted, a fresh agent judges them with
    [references/criteria-judge.md](references/criteria-judge.md), and the
    judge's HTML report is emitted:
 
        outerlayer emit artifact <judge-report>.html --for acceptance-criteria --caption "Each criterion judged against its test"
 
+   Its verdict is recorded on the `acceptance-criteria` check, as release.md
+   says. When the state file holds no criteria, no judge runs and that
+   check gets no result, so it reads "not proven", never passed.
    Watch CI until every check has concluded.
 6. **Manual test and evidence.** Read [references/evidence.md](references/evidence.md)
    when the pull request opens, and run it. Capture the proof each criterion

package/skill-pack/template/build/references/agent-briefs.md

@@ -78,8 +78,10 @@ drives the real chain, from input through storage to read-back, with nothing
 mocked at the store boundary, plus one test per criterion written from the
 criterion's own words. Read every failure. Each test must fail because the
 behavior is absent, not because of a typo or a missing import. Then implement
-until green. When the issue has no criteria, write tests from its description
-in the same order.
+until green. When the build drafted the criteria from the issue's
+description, they are requirements in the same way, and tests cite their
+ids. When no criteria were recorded, write tests from the description in the
+same order.
 
 Version any new database migration with the current UTC time, never a round or
 guessed one. Two open branches that guess the same time both pass their own

package/skill-pack/template/build/references/release.md

@@ -61,12 +61,12 @@ the final report. Never record the result with another link.
 
 ## Judge the criteria
 
-When the issue has criteria, spawn one fresh agent on
-[criteria-judge.md](criteria-judge.md), with the worktree path, the base ref,
-the pull request number, the path of the build's state file, and a report
-path under `build-reports/`. Above forty
-criteria, spawn one judge per group of about forty in the same wave, each with
-its own report path, and merge their results by concatenation.
+When the state file holds criteria, from the issue or drafted, spawn one
+fresh agent on [criteria-judge.md](criteria-judge.md), with the worktree path,
+the base ref, the pull request number, the path of the build's state file,
+and a report path under `build-reports/`. Above forty criteria, spawn one
+judge per group of about forty in the same wave, each with its own report
+path, and merge their results by concatenation into one report.
 
 The judge writes an HTML report with one verdict per criterion. Emit it:
 
@@ -76,8 +76,36 @@ Then run `outerlayer sync`. List every unsatisfied criterion in the final
 report. A criterion that declares a proof form such as a screenshot or video is
 proven only by an artifact bound to it on the pull request. The judge cannot
 see that, so confirm each has an artifact of the declared kind, and emit any
-that is missing in the evidence phase. When the issue has no criteria, no judge
-runs and no judge report is emitted.
+that is missing in the evidence phase.
+
+## Record the criteria verdict
+
+Once the judge's report is synced, copy its deep link from the pull request's
+evidence comment. The link can take up to a minute to appear after the sync.
+If it is not there yet, wait a minute and read the comment again. Never build
+the link by hand, and never link a pull request comment. Then record the
+judge's verdict on the `acceptance-criteria` check, once:
+
+    outerlayer emit acceptance-criteria --item "$OUTERLAYER_WORK" --result pass --link <the judge report's deep link>
+
+The result is the judge's own last line. Record `--result pass` only when it
+reads `result: pass`: every criterion the judge judged is satisfied. Record
+`--result fail` when it reads `result: fail`, because a criterion is not
+satisfied. A fail is recorded as fail, never withheld. With several judges,
+record fail when any one of them failed. A criterion the judge marked
+`not-judged` neither passes nor fails this check: its declared artifact
+proves it on its own row. Drafted criteria are judged and recorded here like
+the issue's own.
+
+When the state file holds no criteria at all (`criteria.source` is `none`,
+for example because drafting found nothing to draft), no judge runs, no
+judge report is emitted, and nothing is recorded on this check. The row
+then reads "not proven" once the build's claim ends. That is deliberate: no
+criterion was judged, so the row must not read as passed, and a fail would
+claim the judge found an unmet criterion. Name the unjudged check in the
+final report. When the link has not appeared after a sync and a second look,
+stop and name it as a blocker in the final report. Never record the result
+with another link.
 
 ## Watch CI
 

package/skill-pack/template/build/references/review-loop.md

@@ -20,12 +20,16 @@ whatever its size.
 
 | Item and diff | Tier | Reviewers | Judge |
 |---|---|---|---|
-| No criteria | small | one generalist | no judge runs |
+| No criteria recorded | small | one generalist | no judge runs |
 | Under ~40 lines, off the floor | small | one generalist | when criteria exist |
 | Up to ~800 lines, off the floor | medium | generalist + one focused reviewer | when criteria exist |
 | Floor, or larger | full | generalist + up to three | when criteria exist |
 
-An item with no criteria is `small` whatever its diff, and no judge runs.
+An item with no criteria recorded is `small` whatever its diff, and no judge
+runs, so the `acceptance-criteria` check gets no result. That happens only when the build could not draft a single criterion, since
+an issue with no criteria gets a drafted list. A drafted list
+(`criteria.source` is `drafted`) is tiered and judged like criteria the issue
+wrote.
 
 - **Small.** One generalist reads the full diff. No focused reviewer and no
   mutation agent. The orchestrator runs the repository's mutation tool itself