10 Commits

Include renames

Author	SHA1	Message	Date
Claudeandclaude[bot]	b44bb82a3a	fix(ci): build push and run links from GITHUB_SERVER_URL (#766) ... night-red.mjs fell back to `https://github.com/<repo>/actions/runs/<id>` when the API did not return html_url, and five publishing steps pushed to `https://x-access-token:$TOKEN@github.com/<repo>`. On github.com nothing breaks today; on any other server (GHES) the links and pushes would point to the wrong host while GITHUB_API_URL is already honoured (#751). - ci-proof.mjs: githubServerUrl(env) - GITHUB_SERVER_URL without a trailing slash, github.com when unset; night-red threads it as `server` into commentBody and nightRed, html_url from the API still wins. - _beta-derived, _process (rebase and review document), _ship-review and release-review: `server="${GITHUB_SERVER_URL:-https://github.com}"` and push_url built from it; every token push uses "$push_url". Tests: the night step executed on a non-standard server writes comment and summary links to that host; every token push in every workflow takes its host from GITHUB_SERVER_URL; the four publishing steps executed with GITHUB_SERVER_URL=https://ghe.example.test push to that host, and to github.com when it is empty. Checked: on the previous workflows and with the hard-coded fallback restored in night-red these tests are red. Issue: #766 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-06 23:05:58 +00:00
Claudeandclaude[bot]	cb97274ea7	test(harness): run workflow steps the way the runner does (#766) ... Thirteen test harnesses executed workflow `run:` bodies with their own bash flags. Four of them used `bash -eo pipefail` "as in Actions", but the runner executes a step without `shell:` as `bash -e {0}`: pipefail comes only from an explicit `shell: bash` or from `set -o pipefail` in the body. The harness supplied protection the step did not have, so a step that lost its pipefail stayed green in tests (#729, #737, #751); the reverse also happened - the #793 guard test was red only because of the harness flag. test/helpers/workflow-step.mjs resolves the shell like the runner (step -> jobs.<id>.defaults.run.shell -> workflow defaults.run.shell -> unset), maps it to the runner's command lines (unset -> `bash -e {0}`, bash -> `bash --noprofile --norc -e -o pipefail {0}`, sh, python, custom templates with {0}), writes the body to a file and executes it by path. Unsupported YAML or shells are refused loudly instead of guessed. All step-executing tests now go through runStep(findStep(...)). Witnesses: a step whose left pipeline side fails is green without a shell (negative test) and red with `shell: bash`, job defaults or `set -o pipefail`; the #751 executed test now also shows that the same real steps without their pipefail line stay green, i.e. the test sees a removed pipefail; a guard fails on any test that runs a step with its own bash flags. TESTING.md rule 7 names the helper. Issue: #766 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-06 23:05:58 +00:00
Matysh	9ebc430983	test(process): align publication summary assertions (#767) ... Keep success and push-refusal assertions in sync with the explicit beta heading. Issue: #767 User-Visible: no	2026-10-05 08:39:31 +03:00
Claudeandclaude[bot]	cf7a9cc4fc	fix(process): reconcile canon and hints with the pipeline after #707–#730 (#748) ... Five places still described the pipeline as it was before code that is already in dev: - the S3 hint of the task packet told the author to push the branch, while the spec lives in the issue body (§2.3, #517) and nothing is pushed before S5 (§11.8); - process-gate printed «FAIL п.9 Gates: light» for a trailer nobody writes or reads, while §10.2 item 9 is the unimplemented release:prerelease verdict check. The check is removed; a contract test ties every RULES key to an implemented item of §10.2 and every finding number to a RULES key; - §10.4 item 4 demanded a heredoc in run:, while #723/#730 and their tests demand the opposite: commit messages echo line by line into a file, comment and summary texts come from code; - the ship merge comment, AUTHOR.md, REVIEWER.md and AGENTS.md named only the pre-beta document, though since #727 the night reads ship code first; - the nightly publication committed «docs: ship review for nightly … перед бетой» with the beta step's Issue: #696. It now has its own subject (the document name), body and Issue: #727; the beta message is unchanged. The browser-guard inventory note still said growth above 200 fails mutation-gate --check; since #699 it is a guideline and --check warns. Its counts now match the inventory: 205, lifecycle 90. Issue: #748 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 16:49:55 +00:00
Claudeandclaude[bot]	ff4e096858	fix(process): integrate runs every pipeline script from one dev snapshot (#749) ... The body of _process.yml is read from dev (@dev, #623), so the flags and formats it passes to scripts are dev's. After "Опубликовать документ ревью" the working copy of job integrate is the task branch, and a show/ship branch with a clean merge is not rebased before review: its scripts/ may lag dev by days. review-doc-guard.mjs silently ignores unknown flags (the anchor lost #726 route and #737 usage), and a stale merge-candidate.mjs merges the old way. Only two calls (#723 push refusal, #726 route) were taken from dev, each with its own extraction, and on ship/reuse the remaining ones ran dev's version anyway: the script version depended on the path. Now one step right after setup-node extracts `git archive origin/dev scripts .github/workflows/validate.yml` into $RUNNER_TEMP/dev-tools and every repo script of the job runs from there via TOOLS (review-result-gate, review-doc-guard, reviews-index, merge-candidate, process-track route, status-label). validate.yml is part of the snapshot because workflow-jobs.mjs reads it relative to itself; without it ci-proof answers `failed (#622)` and every code merge would return to S6. The working copy stays the material: git, the document and paths are judged there. PROCESS.md §10.4 gets the paragraph "Скрипты конвейера — из dev": the model_review exception, merges of pipeline changes judged by dev's version, and compatible edits of the Validate proof contract. Tests: test/process-integrate-tools.test.mjs is the job contract (no step calls scripts/ from the working copy, every call goes through the snapshot, one archive from origin/dev with validate.yml, and the step as is yields a directory where ci-proof resolves the job contract); publish-push-refusal runs the publish step and the #413 step on real bash with a task branch whose review-doc-guard.mjs exits 7 (red with the old call). Existing harnesses take the snapshot step before the publish and decide steps; the #706 mutant anchor follows the status-label call. Issue: #749 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 15:35:16 +00:00
Claudeandclaude[bot]	f5a6b47b39	feat(process): the pipeline records model usage in the review document's machine block (#737) ... The weekly process metrics weigh tracks and the nightly ship review in the order quality, speed, tokens (#707), but the third axis had no source: the claude-code-action step hides usage from the Actions log on purpose, nothing read its execution_file, and the #728 reader printed "no data" every week. scripts/model-usage.mjs is the single module that builds and parses the line: `<!-- hp:usage input_tokens=N output_tokens=N cache_creation_input_tokens=N cache_read_input_tokens=N num_turns=N -->` (sums over every model in the last `result` message, `result.usage` when modelUsage is absent) or `<!-- hp:usage-none reason=<code> -->`. Only the result message is read; the rest of the file holds tool results, and no byte of it is printed. A new step right after Review in both model_review jobs (always(), continue-on-error) hands the line out as the job output `usage`. Usage is a reporting figure like the stage duration, so it travels as a job output and not through the sealed artifact: REQUIRED_FILES and the #556 gate are unchanged. Publication treats the line as untrusted input and writes the normalized form as the last line of the anchor block (review-doc-guard --anchor --usage=) or right after the SHIP-REVIEW block; empty becomes reason=missing, anything off-format reason=invalid. The #728 reader now takes the line only from the machine block: a reviewer quoting the previous round in prose no longer doubles its usage, and "no data" is counted as missing, never as zero. PROCESS.md §10.4 documents the source, the format and why it is a job output. Issue: #737 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 12:18:13 +00:00
Claude	4eb712be0e	fix(process): a workflow-permission refusal tells the author to rebase (#730) ... Review r1 (Medium): refusalSummary said "повтор и ребейз не помогут" for every non-stale outcome, and since AC2 the rebase guard's summary carries it too. For a workflow-permission refusal a rebase and push by the author is exactly the way out (PROCESS.md §10.4). That outcome now says so; other GitHub refusals keep the old sentence. Issue: #730 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 07:48:37 +03:00
Claude	562313944f	fix(process): ship review and beta-derived pushes tell a GitHub refusal from a moved dev (#730) ... After #705 and #723 two more workflow bodies still treated every failed push as a moved dev: the SHIP-REVIEW publication (_ship-review.yml) retried three times with "dev went ahead", and the derived-artifacts bot commit (_beta-derived.yml) told the release manager to rerun the workflow. A refusal by GitHub itself - a token without the workflow right, a branch rule, a hook - is cured by neither, and neither step said what GitHub answered. Both pushes now keep stderr and hand it to the #705 classifier through the same CLI (merge-candidate.mjs --push-refusal). A stale lease keeps the old behaviour: another attempt for the ship review, the rerun advice for the derived artifacts. Any other outcome stops the step at once: the log gets the git answer and the step summary gets the reason and the git answer without secrets (--summary, refusalSummary with the new ship-review and beta-derived labels). The classifier comes from dev, as for the other steps of these bodies: both jobs check out dev, and the ship review resets to origin/dev before every attempt. The ship review commit message is built line by line into a file instead of a heredoc, as in #723. The thin callers ship-review.yml and beta-derived.yml are untouched. The rebase guard in _process.yml also writes the refusal reason to its step summary now (--summary, label "rebase"); a stale lease writes none. test/publish-push-refusal.test.mjs runs both steps as they are with real bash and real git in temporary repositories (moved dev = a real neighbour push, GitHub refusal = recorded stderr with a token, a credential URL and an Authorization header); on the old bodies 10 of its 12 new tests fail. The #705 execution tests of the rebase guard in rebase-generated.test.mjs now also read the step summary. PROCESS.md names the two steps next to the Issue: #730 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 07:48:37 +03:00
Claudeandclaude[bot]	d327ec3d93	feat(process): a failed show verdict re-routes to ask without a fresh budget (#726) ... A non-green show verdict that found "something to decide" went down the same path as "fix the code": S6 with a limit of 2. Promoting the task to track:ask was left to the agent's memory, with no named criterion and no trace, and the exhausted budget only surfaced on the next S7 - after a fix nobody would read. The structured verdict now carries `route` (fix | reclassify) and an optional `criterion` (one of the six show criteria of PROCESS.md section 5). The trust boundary reads a missing route as fix, rejects one outside the dictionary and rejects reclassify on a green verdict. `reviewRoute` in process-track.mjs is the single decision: on a code review of an unconfirmed show it moves the task to track:ask and S3-spec; on an owner-confirmed show it adds `blocked` and asks the owner; anywhere else reclassify degrades to fix with a note. The verdict that spends the last cycle sets review-4 at once; the stage budget is shared across tracks, so promotion changes the limit (4), not the count. The "Решение по вердикту" step makes one `process-track.mjs route` call (from dev, like the track step) and only executes its output: comment from a file, labels from add/remove lists, status via status-label.mjs as before. The track step also emits `confirmed` and a `route_note` for the review prompt; the review document anchor gains a route tail that the old reader still parses; wait-verdict reports the two new pipeline comments. The guard's own spent >= limit check stays as the safety net. Issue: #726 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-10-01 03:06:49 +00:00
Claudeandclaude[bot]	0d85807157	fix(process): publish steps tell a GitHub push refusal from a moved branch (#723) ... Two steps publish a commit and treated every failed push as a moved branch: the release review job (release-review.yml) retried three times with "dev went ahead", and the review document step (_process.yml) rebased and pushed again. A refusal by GitHub itself - a token without the workflow right, a branch rule, a hook - cannot be cured by a retry or a rebase, and the step never said what GitHub answered. Both pushes now keep stderr and hand it to the #705 classifier through the same CLI the rebase guard uses (merge-candidate.mjs --push-refusal). Only a stale lease (rejected / fetch first / stale info) keeps the old retry or rebase. Any other outcome stops the step at once, without retries: the log gets the git answer and the step summary gets the reason and the git answer, both passed through redactSecrets (token, credential URL, Authorization). The review document step takes the classifier from dev, as the rebase guard does: a task branch behind dev may not carry it. The summary text is written by the new --summary option (refusalSummary), not by a multi-line string in run:, and both commit messages are now built line by line into a file instead of a heredoc (PROCESS.md §10.4 item 4). release-review.yml is dispatch-only and is not mirrored to main. PROCESS.md names the rule next to the rebase guard; the #638 trailer witness in test/release-review.test.mjs follows the line-by-line message. test/publish-push-refusal.test.mjs runs both steps as they are with real bash and real git in temporary repositories; only the push transport is replaced: a moved branch is a real neighbour push, a GitHub refusal is a recorded stderr carrying a token, a credential URL and an Authorization header. On the old steps 9 of its 11 tests fail. Issue: #723 User-Visible: no Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018qZfe7YS4rqEMKoVeS3GKd	2026-09-30 22:26:44 +00:00