qargi 0.2.8

Fixed

• qargi local clean RUN also removes the saved scrub record of the run (scrub_ok/RUN-ID in the state, written by qargi review check), so a run that was checked and never applied leaves no record behind.
• qargi release step tells a failed write of the step record in plain words instead of printing raw jq text: when another command marked the step first, it says so and to run again with --again; otherwise it says the record cannot be written and to check that it and its directory can be written and that the record is valid JSON (commands that write the record wait for each other, so another command is not named as the cause). The exit status is unchanged.

Changed

• qargi project attach and qargi project show name the declared gates where they showed only the test command: attach lists them (tier, name, command, feature tier first) after the test command: line of a stored project and says they replace it; project show keeps the answers as JSON on standard output and prints the same list on standard error. Without gates nothing changes.
• qargi marshal handoff lists the declared gates in a == gates section after the features (tier, name, command; they replace test_command), and --json carries them as gates (an empty list without gates). Without gates the note is as before. qargi help and the manual page describe this output, that of project show and project attach above, and the --param gates=JSON of project new.
• The gitflow scaffold (qargi methodology files, and the files qargi project adopt writes) renders the declared gates where it rendered only {{test_command}}: README.md, AGENTS.md, CLAUDE.md and CONTRIBUTING.md list them (name, tier, command) and .github/workflows/test.yml has one job for each gate, named after it (the name is a YAML single-quoted scalar, so the scan reads any name back; a feature-tier gate's job runs on every pull request, a release-tier gate's job only on a pull request from a release/ or hotfix/ branch or when started by hand; the jobs run in parallel while verify runs the gates in order, and CONTRIBUTING.md says so), so the CI scan of release verify finds every job matched. The markdown files write a name and a command as inline code in a fence of backticks longer than any run in them ({{gate_name_code}}, {{gate_command_code}}), so a backtick in a gate does not end the span. The new optional methodology parameter gates (one line of JSON) carries them; a template marks its parts with {{#gates}}, {{^gates}} and a {{#gate}} loop, each alone on its line. qargi project new with --url and --param gates=JSON stores the same gates in the project's answers, so the files, feature verify and the CI scan agree (without --url nothing is stored, as for every answer). A gate name or command, and any methodology parameter, may not hold a character that ends a line (U+2028, U+2029, U+0085, a vertical tab and the like, besides a newline), which would break the YAML and the markdown list. Without gates the files are byte for byte what they were.
• The qargi-flow skill and the gitflow-member pack say that a project may declare gates, that feature verify and release verify run them in order and stop at the first failure, and that a member runs only the checks of its own change (the pack's line about the checks of the touched paths calls them the PROFILE checks, so the word gates means only the declared ones). Their word ceilings in tests/skill-budget.txt are raised by 35 and 22 words, with the reason on the line.
• Every plan-token check except canon apply's now ignores QARGI_NESTED: the checks of branch prune, credential setup lead-push, the marshal owner verbs, project new, attach and adopt, provider accept, provision apply and the cloud instances verbs (agent update, normalize, refresh-prompt) are written QARGI_NESTED='' need_plan, as those of release, local, feature, upstream and backlog already were, so a nested environment can no longer apply a plan without its token. The verbs that clear the variable themselves (memory, tier writes, packs, project link) are unchanged, and canon apply still honours it because provisioning runs it that way. A new test, tests/test_nested_plan.sh, covers one verb of each file and checks statically that every need_plan call in lib/ is prefixed or on a short list with its reason (canon apply, and the verbs that unset the variable first).