Conversation
From a single-target derived-repo re-sync (#203): bump the four lagging action pins repo-wide so the template leads (setup-dotnet v5.3.0, checkout v7.0.0, upload-artifact v7.0.1, download-artifact v8.0.1), and affirm the name-pattern artifact handoff (release-asset-<branch>-* + merge-multiple) as canonical for every repo including single-target, documented in AGENTS.md.
Foundation for orchestrating template→downstream re-sync from one session. Because per-machine agent memory is lost on a machine switch, the reusable playbook must live in a committed file. ## What - **New `AGENTS.md` subsection "Orchestrated Re-Sync: Hub and Downstream Personas"** (hub-only, under "Staying in Sync"): defines the **hub/orchestrator** persona (owns source of truth, drives consolidation, **validates each downstream result** for full-replacement + comment discipline + EOL/lint, fixes template gaps through the gate, never merges without maintainer OK) vs the **downstream/derived** persona (full-replace under direction, honor comment rules, report gaps upstream). - **Strengthened the "Staying in Sync" rule**: re-sync is **full replacement** of carried artifacts (replace whole file/section, never partial hand-merge), and is **not** an occasion to add or grow comments. ## Why Targets the two recurring downstream regressions observed across re-syncs: agents doing *partial* updates where carry means full replacement, and accreting comments that violate the Comments rules. The orchestrator now catches both by diffing every result against the template. Docs-only; markdownlint clean; line endings preserved. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Surfaced by Copilot during the NxWitness re-sync ([#448](ptr727/NxWitness#448)) — a real regression from the `pull_request_target` switch (#201). Under `pull_request_target`, `github.ref` resolves to the **base branch**, so the merge-bot concurrency group `…-${{ github.ref }}` serialized *every* bot PR against a base into one queue — delaying auto-merge/disable when multiple Dependabot/codegen PRs are open. Keying on `github.event.pull_request.number` restores per-PR scoping (a PR's events still process in arrival order; different PRs run concurrently). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…eadme, carry-whole-file (#207) Phase-0 of the template-to-downstream convergence sweep: the template absorbs everything downstream repos had reinvented, so derived repos can take the carried artifacts verbatim with zero hand-rolling. Builds on #205 (orchestration personas) and #206 (per-PR merge-bot concurrency), which this branch incorporates. Held for end-gate review; not to be merged midway. ## What this PR does - **Absorbs downstream-led action pins** (template now leads per #204): `dependabot/fetch-metadata` v2.5.0 -> v3.1.0 and `softprops/action-gh-release` v2.6.2 -> v3.0.1, the SHAs the downstreams already run. - **Generalizes the release model + adds a loud guard.** Every release is a tag on the built commit plus an auto source zip, README, and LICENSE; targets amend it by uploading `release-asset-<branch>-*` artifacts (binaries/packages) or pushing elsewhere (image/registry). `github-release` collects assets by the `release-asset-<branch>-*` pattern so the job is target-agnostic and carries verbatim. - **Makes the Docker README + date badge main-only, caller-gated.** Neither has per-branch context, so both move out of the publisher branch matrix into single jobs gated on `main` being published. `publish-docker-readme-task.yml` is rebuilt generic: a matrix over a `repositories` input (or a manifest-derived list), a caller-passed `ref`, and an optional transform step (e.g. m4) to render the README before pushing. - **Adopts the carry-whole-file rule.** Replaces "drop the sections you don't ship": derived repos carry each shared file in full (an inert `[*.cs]` block or unused-language `CODESTYLE.md` section costs nothing), so every re-sync is a clean overwrite, not a partial merge. `CODESTYLE.md` is genericized into a self-contained drop-in (no demo-project names, no template-onboarding pointers) and carries both the .NET and Python sections whole. Only per-language `.vscode/tasks.json` task definitions still track the repo's language. All carried files stay self-contained (no template/demo/cross-project references except the sanctioned upstream-drift pointer). Workflow YAML and Markdown remain CRLF per the line-ending governance. Validated with actionlint and markdownlint-cli2 (clean). ## Documented adaptations (for review) These are the genuine, intentional deviations the maintainer should review at the end gate. Each is a sanctioned exception with its rationale recorded inline in the artifact; nothing here is accidental drift. - **`fail_on_unmatched_files: true` on `github-release`** - a promised `release-asset-*` that goes missing or is misnamed fails the release loudly; a Docker-only / no-file-target repo is the one case that relaxes it (no release asset to attach). - **`merge-bot-pull-request.yml` concurrency: per-PR group, `cancel-in-progress: false`** - under `pull_request_target` `github.ref` is the base branch, which would serialize every bot PR against that base, so the group keys on the PR number; cancellation would leave auto-merge in an inconsistent state, so events queue and each runs to completion. - **`publish-release.yml` concurrency: global ref-independent group, `cancel-in-progress: false`** - it publishes shared ref-independent artifacts (both branches' Docker tags/caches and GitHub releases) regardless of the triggering ref, so a ref-scoped group would let a scheduled run and a manual dispatch double-push; cancelling mid-flight can leave a partial tag set or half-created release. - **`dotnet/nbgv` consumed via `@master` (no SHA pin)** - the upstream tag stream lags `master` substantially and Dependabot's tag-tracking would propose a downgrade; this is the one documented no-SHA-pin exception. - **Ruleset-bound job name kept verbatim (no "job" suffix)** - `Check pull request workflow status` in `test-pull-request.yml` is referenced as a required-status-check `context:` in the branch ruleset; renaming it to fit the "every job name ends in job" convention would silently break required-status-check enforcement. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…n workspace files and adding a unified ProjectTemplate workspace file (#210) Signed-off-by: Pieter Viljoen <ptr727@users.noreply.github.com> Signed-off-by: Pieter Viljoen <ptr727@users.noreply.github.com>
) ## Problem Closes #213. `publish-release.yml` dispatched from `main` builds a matrix of both `main` and `develop`. NBGV derives `PublicRelease` from the runner's `GITHUB_REF`, which is `refs/heads/main` for **every** leg regardless of the ref each leg checks out. So the `develop` leg is classified public, NBGV strips its `-g<sha>` prerelease suffix, and the **develop NuGet package is published as a stable version** (`isPrerelease=false`) — consumers can resolve a develop build as if stable. The GitHub release object stays `prerelease:true`, masking the bug. ## Fix - **`get-version-task.yml`**: optional `branch` input pins the `GITHUB_REF`/`GITHUB_REF_NAME` NBGV reads to the leg being versioned (fallback to `github.ref` when empty). The mislabel originates in `build-nugetlibrary-task`'s own get-version call, so `branch` is threaded from **all five** callers (`build-release-task` + the four `build-*-task` files). - **Validate at entry**: the late, one-directional "Verify public release version" step (main-only, mid-flow in `github-release`) is replaced by a single `validate-release` job that the build jobs `needs:`. It checks branch↔version consistency **both** directions — `main` must carry **no** prerelease `-`; every other branch **must** carry one (the #213 regression guard) — and fails fast **before** the expensive builds. - **Pattern**: codified "validate input/state consistency at entry, fail fast" in `AGENTS.md` "Workflow YAML Conventions", generalizing the existing `publish-docker-readme-task.yml` "Validate inputs step". ## Verification - `actionlint` (Docker) clean on all six changed workflows; markdownlint clean on `AGENTS.md`; CRLF preserved. - Live proof (post-merge): dispatch `publish-release` from `main`, confirm the develop leg's `SemVer2` regains `-g<sha>` and the NuGet package is `isPrerelease=true`; `validate-release` fails a clean-`X.Y.Z` develop version. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…lete (#216) ## Problem Closes #214. The `cleanup-artifacts` job (duplicated in `test-pull-request.yml` and `publish-release.yml`) blanket-deleted **every** run artifact (`.artifacts[].id`). It was added to stop huge `release-asset-*` artifacts (`KiCadLibrary`) filling the storage quota, but it **overstepped** — it also destroys diagnostic/log artifacts and the build-records actions emit automatically, exactly what you need to debug a failed run. ## Fix Per maintainer guidance: surgical cleanup + `retention-days: 1` + normal failed-job surfacing, **no** naming-pattern terminal backstop (overkill). - **Consume-then-delete**: each transfer artifact is deleted by exact name/pattern at the job that consumes it — the `github-release` job deletes `release-asset-<branch>-*` after attaching them to the release; `publish-pypi` deletes `pypilibrary-build-<branch>` after publishing. - **Permissions**: `actions: write` granted where deletion happens — at the `publish` caller for the reusable `github-release` job, and on `publish-pypi` directly (was `actions: read`). - **Removed** the blanket `cleanup-artifacts` job from both workflows. `retention-days: 1` (already on every transfer upload) is the failure-path backstop; a failed run is reported normally. Diagnostics/build-records survive — the intended outcome. - **Pattern**: rewrote the AGENTS.md "Artifact retention" rule to the consume-then-delete shape so downstream customizations honor it. ## Verification - `actionlint` (Docker, bundles shellcheck) clean on all three changed workflows; markdownlint clean on `AGENTS.md`; CRLF preserved. - `check-workflow-status` (the required-status-check aggregator) does not depend on the removed job, so the merge gate is unaffected. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
) ## Problem Closes #211. Branch rulesets are live GitHub config applied once at repo creation, so they sit **outside** the file-based re-sync loop (AGENTS.md "Staying in Sync"). Two consequences: a corrected template ruleset never propagates to existing derived repos, and downstream ruleset drift is invisible. This bit `ptr727/PlexCleaner` — its synced docs said `strict=false` while its live rulesets stayed `strict=true` on both `develop` and `main` (the exact #82 failure mode), fixed locally only after it broke auto-merge and blocked a promotion. ## Change - **Canonical rulesets as committed files, maintained in this template only.** `.github/rulesets/develop.json` and `.github/rulesets/main.json` hold the re-importable writable subset (`{name, target, enforcement, bypass_actors, conditions, rules}`), `strict_required_status_checks_policy: false` on both. They port verbatim with no placeholders — `conditions` key on `refs/heads/{develop,main}`, `bypass_actors` uses the global Admin role `actor_id: 5`, the required check binds by name. - **README "Rules / Rulesets"** repoints the source of truth to these committed files: setup imports from them; the live export becomes the regenerate recipe run in the template when the maintainer changes the live rulesets. - **AGENTS.md** documents that the rulesets are deliberately **not** in the verbatim-carry set and are **not** carried/re-synced downstream as a per-repo copy — they are live config, not a file a derived repo consumes. They ride the re-sync loop **from the hub**: diff each derived repo's *live* rulesets against the template's committed JSON and correct drift via a full-payload PUT. The drift command normalizes `rules[]`/`bypass_actors[]` order so a reordered-but-equivalent ruleset doesn't read as drift. - Also folds in pending spell-dict / workspace-extension additions (and mirrors the two new general extensions into both devcontainers). ## Verification - `jq -S` round-trip stable for both files; order-normalized drift diff against the template's own live rulesets reports `develop: in sync` / `main: in sync`. - Ran the drift check across all 8 derived repos (read-only): 6 in sync, `Utilities` has real live drift, `homeassistant-purpleair` has no rulesets configured — both surfaced to the maintainer (issues filed), not auto-applied. - markdownlint-cli2 clean on README.md and AGENTS.md (0 errors). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Problem Closes #217. In `build-release-task.yml`'s `github-release` job the two paired steps had mismatched conditions: - **Create GitHub release step** — `if: exists == 'false' || workflow_dispatch` - **Delete consumed release asset artifacts step** — `if: expect_release_assets` On a scheduled run where the release tag already exists (no new commits), the create step is skipped but `build-nugetlibrary` still uploaded `release-asset-<branch>-*`, so the delete step removed the freshly built artifacts even though nothing was published/refreshed this run. Low impact (`retention-days: 1` means nothing is permanently lost) but the delete's premise ("durable copies now on the release") doesn't hold for that run. ## Fix Gate the delete on the same condition as the create step: ```yaml if: ${{ inputs.expect_release_assets && (steps.release-exists.outputs.exists == 'false' || github.event_name == 'workflow_dispatch') }} ``` So it only deletes when a release was actually created/refreshed; otherwise the fresh artifacts stay for the run and `retention-days: 1` reaps them. Surfaced via Copilot during the downstream re-sync of #213/#214 (ptr727/LanguageTags#195) and reported upstream rather than diverged locally. ## Verification - `actionlint` (Docker) clean; CRLF preserved. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Problem Closes #219. The `validate-release` entry gate (added in #213/#215) runs **unconditionally**, including in PR **smoke** builds. A smoke build checks out the PR head in detached HEAD, so NBGV always computes a prerelease version (`X.Y.Z-g<sha>`). On a **main-base** PR — a `develop → main` promotion carrying a build target — the gate's `branch == 'main'` arm fails: ``` ::error::Public (main) release version 'X.Y.Z-g<sha>' carries a prerelease suffix; refusing to publish. ``` `validate-release` fails → `build` is skipped → the required `Check pull request workflow status` fails. **Every clean `develop → main` promotion PR that includes a build-target change is blocked by its own smoke build** (masked only when merged via admin bypass). ## Fix Skip the gate for smoke builds — they never publish — keeping the job in the graph as a **success** so `build-*`'s `needs: [get-version, validate-release]` stays satisfied: ```yaml SMOKE: ${{ inputs.smoke }} ... if [[ "$SMOKE" == "true" ]]; then echo "Smoke build; skipping release version validation." exit 0 fi ``` Real publishes (`smoke: false`) still get both-direction validation. ## Verification - `actionlint` (Docker, shellcheck-bundled) clean; CRLF preserved. - Per the issue's push-probe: a `smoke: true` invocation passes for both `branch: main` (Release) and `branch: develop` (Debug) with `github-release` skipped; real publishes unaffected. Found via end-to-end CI flow validation during the #213/#214 downstream re-sync. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ride (#222) ## Problem Closes #221; supersedes the mechanism from #215. The #213 fix (PR #215) restored the develop leg's prerelease tag by overriding `GITHUB_REF` in the nbgv step `env:`. **It doesn't work.** `GITHUB_REF` is GitHub-reserved — a step-level `env:` can't reliably override it (the runner re-injects the dispatch ref). NBGV's GitHub Actions cloud-build provider reads `GITHUB_REF` for `BuildingRef`, so on a publish dispatched from `main` the develop leg was still classified public and would publish a **clean (stable)** version. CI evidence from the first real publish after #215: ``` GITHUB_REF: refs/heads/develop # the step-env override (as configured) "BuildingRef": "refs/heads/main" # NBGV still saw the dispatch ref "PublicRelease": true "SemVer2": "1.4.2" # clean, no -g suffix ``` (The `validate-release` gate correctly blocked the bad publish, so nothing shipped — but the develop prerelease leg never publishes.) ## Fix NBGV versions from the **checked-out branch** unless its cloud provider overrides with `GITHUB_REF`. Each matrix leg already checks out its own branch, so set NBGV's own `IGNORE_GITHUB_REF=true` to make it ignore the CI ref: ```yaml - name: Run Nerdbank.GitVersioning tool step id: nbgv uses: dotnet/nbgv@master env: IGNORE_GITHUB_REF: true ``` - Removed the ineffective `GITHUB_REF`/`GITHUB_REF_NAME` override. - Dropped the now-useless `branch` input from `get-version-task.yml` and its threading from all five callers (`build-release-task` + the four `build-*-task`). - `validate-release` entry gate (from #213/#215, smoke-skip from #219) **stays** as the backstop. NBGV source confirms the knob: `BuildingRef => IgnoreGitHubRef ? null : env GITHUB_REF`. ## Verification - `actionlint` (Docker) clean on all six changed workflows; CRLF preserved. - Per the issue's CI probe (real `dotnet/nbgv`): `develop` checkout + `IGNORE_GITHUB_REF=true` → `PublicRelease=False`, `1.4.2-g…`; `main` → `True`, `1.4.3`; `main` without the flag reproduces the bug. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…est methodology (#223) ## Why A week-plus of template work surfaced ~40 workflow issues/PRs and a cascade of **behavioral** defects (a leg published as stable; cleanup that orphaned the quota then destroyed diagnostics then deleted still-needed assets; a gate that blocked every promotion; an override that did nothing). Each was an *outcome* failure that cost rounds of PRs to find. There was no single artifact stating **what a workflow must do** and **how to prove it**. ## What `WORKFLOW.md` at the repo root — a standalone guide, sibling to `CODESTYLE.md`, mixing **code style**, **architecture**, a **behavioral contract** (expected inputs→outputs), and a **test methodology**. Defining principle: **contract, not implementation.** A repo's workflows may be shaped differently; they must *satisfy the contract* and be *defect-free against the expected inputs/outputs*. Given the doc, an agent can **audit** (static), **test** (trace + probe), and **assess** (operational / not). - **§2** style conventions · **§3** architecture · **§4** the contract — nine domains (D1 fast-feedback, **D2 input/state validation**, D3 versioning, D4 release, **D5 resource cleanup**, D6 seam, D7 concurrency/permissions, D8 bots, D9 style), each guarantee = input→output + the **failure-mode it prevents**, portable (no issue numbers) · **§5** test methodology — static-audit checklist, eleven end-to-end trace scenarios (S1–S11), live probe, binary verdict with an explicit **N/A / applicability** rule · **§6** per-project-type walkthroughs. ## Hardening (multi-agent per-type review, converged) Six per-domain assessors (console, NuGet, PyPI, Docker, data/asset, source-only) each used the doc to audit/test/assess **their** project type against the real workflows, over three rounds: - **Round 1** (v1→v2): dense feedback across all six. Cross-cutting fixes: define **applicable/N-A** (near-empty pipelines are mostly N/A, not failing); disambiguate orchestrator-vs-leaf input layers; a no-file-target repo reaches the tag-only shape only by its caller passing `expect_release_assets:false`; D1.2 is a *type-appropriate* validation job (non-.NET repos replace it); NBGV/`version.json` retained even by no-compiler repos; adding/dropping a target edits the orchestrator surface. Plus per-type precision (PyPI `.dev0` from AssemblyFileVersion; PyPI unconditional post-publish cleanup; executable intermediates on the retention backstop; D3.5 wrapper is a tracker skeleton; NuGet snupkg; new S11 wrapper-bump scenario; 7z-not-zip; …). - **Round 2** (v2→v3): four assessors **NO ACTIONABLE FEEDBACK**; Docker + data/asset raised 2 minors each (buildcache per-branch-not-per-image; wrapper-only 5A marker; re-point `smoke-build`'s `needs` too; S9 schedule-vs-dispatch). - **Round 3**: all re-checked domains **NO ACTIONABLE FEEDBACK**. **Converged.** ## Verification - `markdownlint-cli2` clean; CRLF per `.editorconfig`; no template issue numbers (portability). - **Dogfood:** the §5A static checklist run against this repo's own workflows reports **20/20 → OPERATIONAL** at every revision. ## Scope New file only. The `AGENTS.md` "Workflow YAML Conventions" / "Release Model" reconciliation (move + pointer, like `CODESTYLE.md`) is **deferred until this doc is ratified** — noted inline at the top of the file. Requesting **ratification** before the AGENTS.md reconciliation and downstream rollout. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Promotes accumulated develop workflow/process changes to main, including a new CI/CD workflow contract document, updated workflow architecture/guards, and supporting repo hygiene updates (rulesets-as-JSON, workspace/devcontainer consolidation, and line-ending enforcement).
Changes:
- Add
WORKFLOW.mddefining GitHub Actions workflow style, architecture, behavioral contract, and validation methodology. - Harden CI/CD workflows: branch-correct versioning (NBGV), validate-at-entry, surgical artifact cleanup at consumption, and main-only gating for badge/Docker Hub overview updates.
- Codify rulesets as committed JSON and update repo docs/config to support deterministic re-sync and consistent line endings (including Dockerfile LF enforcement).
Reviewed changes
Copilot reviewed 25 out of 26 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| WORKFLOW.md | New workflow contract/style/verification guide for .github/workflows/**. |
| README.md | Updates ruleset setup guidance to import committed JSON; adds deferred improvement note. |
| Python.code-workspace | Removes legacy Python-only workspace in favor of unified workspace. |
| ProjectTemplate.code-workspace | Expands unified workspace settings/extensions (incl. Python tooling + actionlint/shellcheck). |
| Docker/Dockerfile | Reformatted/reflowed Dockerfile (no functional changes apparent from diff). |
| CODESTYLE.md | Shifts to “carry whole file” model; generalizes language sections and clean-compile guidance. |
| AGENTS.md | Updates carry/replace guidance (carry whole files), ruleset reconciliation instructions, and workflow cleanup conventions. |
| .github/workflows/test-pull-request.yml | Pins updated actions/* SHAs; removes terminal blanket artifact cleanup job. |
| .github/workflows/run-codegen-pull-request-task.yml | Pins updated actions/* SHAs. |
| .github/workflows/publish-release.yml | Grants actions: write for surgical cleanup, updates artifact download action, and gates badge/readme jobs to main. |
| .github/workflows/publish-docker-readme-task.yml | Refactors into generic reusable task with repo-list derivation, input validation, optional transform, and matrix publish. |
| .github/workflows/merge-bot-pull-request.yml | Fixes concurrency grouping to be per-PR (not base branch) and updates Dependabot metadata action pin. |
| .github/workflows/get-version-task.yml | Sets NBGV IGNORE_GITHUB_REF to version from checked-out branch; updates actions/* pins. |
| .github/workflows/check-upstream-version-task.yml | Updates actions/checkout pin. |
| .github/workflows/build-release-task.yml | Adds expect_release_assets, adds validate-at-entry validate-release job, updates action pins, and implements surgical asset cleanup after release creation/refresh. |
| .github/workflows/build-pypilibrary-task.yml | Updates checkout/upload-artifact pins. |
| .github/workflows/build-nugetlibrary-task.yml | Updates setup-dotnet/checkout/upload-artifact pins. |
| .github/workflows/build-executable-task.yml | Updates setup-dotnet/checkout/download-artifact/upload-artifact pins. |
| .github/workflows/build-docker-task.yml | Updates checkout pin. |
| .github/workflows/build-datebadge-task.yml | Caller-gated behavior; updates BYOB action pin and removes main-branch self-gate. |
| .github/rulesets/main.json | Adds committed, versioned ruleset JSON for main. |
| .github/rulesets/develop.json | Adds committed, versioned ruleset JSON for develop. |
| .gitattributes | Adds LF enforcement pins for *.sh and Dockerfiles while keeping * -text default. |
| .editorconfig | Enforces LF for Dockerfiles via [{Dockerfile,*.Dockerfile}]. |
| .devcontainer/python/devcontainer.json | Updates extension mirror comment and adds actionlint/shellcheck extensions. |
| .devcontainer/dotnet/devcontainer.json | Updates extension mirror comment and adds actionlint/shellcheck extensions. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Promote the accumulated
developwork tomain. Twelve changes since the last promotion:WORKFLOW.md: workflow style, architecture, behavioral contract, test methodology (Add WORKFLOW.md: workflow style, architecture, behavioral contract, test methodology #223)IGNORE_GITHUB_REFinstead of the ineffectiveGITHUB_REFoverride (Use NBGV IGNORE_GITHUB_REF instead of the ineffective GITHUB_REF override #222)github.ref(Key merge-bot concurrency on PR number, not github.ref #206)🤖 Generated with Claude Code