feat(contracts): C3 workflow-API drift gate (schema exists Phase 0b/#504; gate keeps it honest) #586

Merged

bosun merged 1 commit from i/583-workflow-api-drift-gate into main 2026-07-27 17:33:15 +02:00

Conversation 1 Commits 1 Files changed 3 +322 -4

engineer commented 2026-07-27 17:26:17 +02:00

Owner

Copy link

What

Phase 7 (#80) tracker #583, reframed at framing-verify: the C3 workflow-API JSON schema already exists (docs/architecture/contracts/workflow-api.schema.json, authored Phase 0b/#504). The residual — and the value the tracker was actually reaching for — is a toolkit-side drift-validation gate that keeps that schema honest against the substrate it describes.

Ratified fork Option 1 (bus 75ae → Bosun ratify): a Go test that lifts reusable-release.yml's on.workflow_call.{inputs, outputs} and cross-checks it against the schema, so a change to the input/output surface reds at PR time on the toolkit rather than at a consumer's cut time. Rejected Option 2 (consumer-side uses:+with: validation) as a non-goal — architecturally awkward, no standard tool, would need novel tooling.

Refs #583 · Phase 7 milestone #80.

Why the schema could silently rot

The schema is referenced by nothing today. So a PR that renames/adds/removes an input, flips its required-ness, or changes a default would leave the schema describing a workflow_call surface that no longer exists — and the C3 contract (the toolkit's adopter-compatibility promise, ADR-0008 §1) would quietly stop being true, with no signal. The gate closes that gap.

The gate — internal/contracts (test-only package)

TestWorkflowAPISchemaMatchesReusableRelease lifts the workflow's on.workflow_call.{inputs, outputs} via yaml.v3 and cross-checks the dimensions both artifacts carry:

Check	workflow side	schema side
input names	on.workflow_call.inputs keys	$defs.inputs.properties keys
input required	inputs.<n>.required: true	$defs.inputs.required[]
input defaults	inputs.<n>.default	$defs.inputs.properties.<n>.default
output names	on.workflow_call.outputs keys	$defs.outputs.properties keys

These are exactly the dimensions the §Stability guarantee freezes (rename / add / remove / retype / default-change).

What is NOT cross-checked, and why (surfaced explicitly, not silently dropped): enums + minLength are schema-only refinements over the workflow's bare type: string — the workflow has no counterpart to compare against; output required-ness (mode "always populated") is a schema semantic workflow_call has no field for. TestWorkflowAPISchema_InternalConsistency validates those for internal consistency instead: a declared default is a member of its enum, and every required name is a declared property.

Vacuity guard (signal-may-be-empty discipline): the loaders t.Fatalf on a zero-length lift (e.g. if the on:/workflow_call: key resolution ever breaks) rather than passing on a surface never read. on is deliberately parsed as the string key by yaml.v3's YAML-1.2 resolution (not the YAML-1.1 boolean true); the guard fails loud if that stops holding.

Non-vacuity — the gate IS the mutation-control

Renamed dry_run → dry_run_MUTATION in reusable-release.yml's inputs; observed the RED, reverted by re-edit, observed GREEN:

--- FAIL: TestWorkflowAPISchemaMatchesReusableRelease/input_names
    inputs in reusable-release.yml but MISSING from workflow-api.schema.json: [dry_run_MUTATION]
    inputs in workflow-api.schema.json but MISSING from reusable-release.yml: [dry_run]

Reverted by re-edit (never git checkout); grep -rn MUTATION clean; reusable-release.yml byte-unchanged (not in the diff). The defaults subcheck correctly stayed silent under the mutation (it compares only names present on both sides) — clean axis isolation.

Docs reconciliation

workflow-api.md previously asserted "a JSON-Schema form is not used here" — which contradicted the existing schema file. Updated to: reference workflow-api.schema.json + the gate, explain it validates a normalized {inputs, outputs} lift (not a raw workflow_call block), and document consumer-side validation as an explicit non-goal with rationale. The §Stability additive-only rule is preserved (already correct).

What this PR does NOT do (deferred to Wednesday+ per budget)

• No consumer-side validation recipe (Option 2 non-goal; may get its own tracker if empirical need surfaces).
• No new jsonschema dependency — the property is name/required/default parity, a structural cross-check; a full JSON-Schema validator would be substrate the scope doesn't earn (same principle as #557 reject-B).
• No sibling C1/C2 (config/manifest) drift gates — they have their own validation paths; a gate could join internal/contracts later if needed (noted in doc.go).
• No touch to #582/#584/#585/#562/#580 — one-tracker budget scope.

Reframe / substrate-honesty note

Original tracker title said "consumer breakage catchable at PR time"; the schema's actual design catches toolkit surface-drift. That title-vs-substrate mismatch was surfaced at framing-verify (bus 75ae) and the tracker body was reframed by Bosun before build — filed as Phase 7 correction-cycle instance 1.

Gate

Full gate green on host and forgejo-ci-go:latest (go1.26.2): golangci-lint 0 issues, go build ./..., go vet ./..., whole go test -count=1 ./..., gofmt -l clean. No bash touched (shellcheck n/a).

AC (reframed, per patched #583)

• Schema exists (already done from #504)
• Drift-validation gate: Go test lifts workflow_call surface + cross-checks against schema; reds on drift
• Gate mutation-verified non-vacuous (rename input → reds; revert → greens; 0 residue)
• Schema referenced from workflow-api.md (was unreferenced)
• Consumer-side validation documented as non-goal with rationale
• go vet ./... + golangci-lint run clean

## What Phase 7 (#80) tracker **#583**, reframed at framing-verify: the C3 workflow-API JSON schema **already exists** (`docs/architecture/contracts/workflow-api.schema.json`, authored Phase 0b/#504). The residual — and the value the tracker was actually reaching for — is a **toolkit-side drift-validation gate** that keeps that schema honest against the substrate it describes. Ratified fork **Option 1** (bus 75ae → Bosun ratify): a Go test that lifts `reusable-release.yml`'s `on.workflow_call.{inputs, outputs}` and cross-checks it against the schema, so a change to the input/output surface reds **at PR time on the toolkit** rather than at a consumer's cut time. Rejected **Option 2** (consumer-side `uses:+with:` validation) as a non-goal — architecturally awkward, no standard tool, would need novel tooling. Refs #583 · Phase 7 milestone #80. ## Why the schema could silently rot The schema is referenced by **nothing** today. So a PR that renames/adds/removes an input, flips its required-ness, or changes a default would leave the schema describing a `workflow_call` surface that no longer exists — and the C3 contract (the toolkit's adopter-compatibility promise, ADR-0008 §1) would quietly stop being true, with no signal. The gate closes that gap. ## The gate — `internal/contracts` (test-only package) `TestWorkflowAPISchemaMatchesReusableRelease` lifts the workflow's `on.workflow_call.{inputs, outputs}` via yaml.v3 and cross-checks the dimensions **both** artifacts carry: | Check | workflow side | schema side | |-------|---------------|-------------| | input names | `on.workflow_call.inputs` keys | `$defs.inputs.properties` keys | | input required | `inputs.<n>.required: true` | `$defs.inputs.required[]` | | input defaults | `inputs.<n>.default` | `$defs.inputs.properties.<n>.default` | | output names | `on.workflow_call.outputs` keys | `$defs.outputs.properties` keys | These are exactly the dimensions the §Stability guarantee freezes (rename / add / remove / retype / default-change). **What is NOT cross-checked, and why** (surfaced explicitly, not silently dropped): enums + `minLength` are schema-only refinements over the workflow's bare `type: string` — the workflow has no counterpart to compare against; output required-ness (`mode` "always populated") is a schema semantic `workflow_call` has no field for. `TestWorkflowAPISchema_InternalConsistency` validates those for **internal** consistency instead: a declared default is a member of its enum, and every required name is a declared property. **Vacuity guard** (signal-may-be-empty discipline): the loaders `t.Fatalf` on a zero-length lift (e.g. if the `on:`/`workflow_call:` key resolution ever breaks) rather than passing on a surface never read. `on` is deliberately parsed as the string key by yaml.v3's YAML-1.2 resolution (not the YAML-1.1 boolean `true`); the guard fails loud if that stops holding. ## Non-vacuity — the gate IS the mutation-control Renamed `dry_run` → `dry_run_MUTATION` in `reusable-release.yml`'s inputs; observed the RED, reverted by re-edit, observed GREEN: ``` --- FAIL: TestWorkflowAPISchemaMatchesReusableRelease/input_names inputs in reusable-release.yml but MISSING from workflow-api.schema.json: [dry_run_MUTATION] inputs in workflow-api.schema.json but MISSING from reusable-release.yml: [dry_run] ``` Reverted by re-edit (never `git checkout`); `grep -rn MUTATION` clean; `reusable-release.yml` byte-unchanged (not in the diff). The defaults subcheck correctly stayed silent under the mutation (it compares only names present on both sides) — clean axis isolation. ## Docs reconciliation `workflow-api.md` previously asserted *"a JSON-Schema form is not used here"* — which **contradicted the existing schema file**. Updated to: reference `workflow-api.schema.json` + the gate, explain it validates a *normalized* `{inputs, outputs}` lift (not a raw `workflow_call` block), and document **consumer-side validation as an explicit non-goal** with rationale. The §Stability additive-only rule is preserved (already correct). ## What this PR does NOT do (deferred to Wednesday+ per budget) - **No consumer-side validation recipe** (Option 2 non-goal; may get its own tracker if empirical need surfaces). - **No new jsonschema dependency** — the property is name/required/default *parity*, a structural cross-check; a full JSON-Schema validator would be substrate the scope doesn't earn (same principle as #557 reject-B). - **No sibling C1/C2 (config/manifest) drift gates** — they have their own validation paths; a gate could join `internal/contracts` later if needed (noted in doc.go). - **No touch to #582/#584/#585/#562/#580** — one-tracker budget scope. ## Reframe / substrate-honesty note Original tracker title said *"consumer breakage catchable at PR time"*; the schema's actual design catches **toolkit surface-drift**. That title-vs-substrate mismatch was surfaced at framing-verify (bus 75ae) and the tracker body was reframed by Bosun before build — filed as Phase 7 correction-cycle instance 1. ## Gate Full gate green on host **and** `forgejo-ci-go:latest` (go1.26.2): `golangci-lint` 0 issues, `go build ./...`, `go vet ./...`, whole `go test -count=1 ./...`, `gofmt -l` clean. No bash touched (shellcheck n/a). ## AC (reframed, per patched #583) - [x] Schema exists (already done from #504) - [x] Drift-validation gate: Go test lifts workflow_call surface + cross-checks against schema; reds on drift - [x] Gate mutation-verified non-vacuous (rename input → reds; revert → greens; 0 residue) - [x] Schema referenced from `workflow-api.md` (was unreferenced) - [x] Consumer-side validation documented as non-goal with rationale - [x] `go vet ./...` + `golangci-lint run` clean

engineer added this to the Phase 7 — Workflow integration milestone 2026-07-27 17:26:17 +02:00

engineer added 1 commit 2026-07-27 17:26:17 +02:00

feat(contracts): C3 workflow-API drift gate (schema exists Phase 0b/#504; gate keeps it honest) ... c179ade228

Wire a toolkit-side drift-validation gate for the C3 workflow-API schema
(docs/architecture/contracts/workflow-api.schema.json, authored Phase 0b/#504).
The schema is the machine-checkable form of reusable-release.yml's workflow_call
{inputs, outputs} surface, but nothing referenced it — so it could silently rot:
an input rename/add/remove, a required-flip, or a default change would leave the
schema describing a surface that no longer exists, and the C3 contract would
quietly stop being true.

internal/contracts (a test-only package) lifts reusable-release.yml's
on.workflow_call.{inputs, outputs} via yaml.v3 and cross-checks it against the
schema:
- input NAMES parity   (workflow inputs  <-> $defs.inputs.properties)
- input REQUIRED parity (workflow required:true <-> $defs.inputs.required)
- input DEFAULT parity  (workflow default <-> $defs.inputs.properties[].default)
- output NAMES parity  (workflow outputs <-> $defs.outputs.properties)
Any drift reds at PR time ON THE TOOLKIT, not at a consumer's cut time.

Enums + minLength are schema-only refinements over the workflow's bare
`type: string` (no workflow counterpart), and output required-ness is a schema
semantic workflow_call has no field for — so those are validated for internal
consistency (a default is a member of its enum; a required name is a declared
property) instead of cross-checked. Loaders fail loud on an empty lift (vacuity
guard) rather than passing on a surface never read.

No substrate accretion: no new deps (yaml.v3 already present + stdlib json — no
jsonschema lib; the property is name/required/default PARITY, a structural
cross-check, not arbitrary-document validation), no Cutter/forgejo/gates/cmd-rt
change. Adds a Go test package + a docs cross-reference only. Same shape as #559's
pure-orchestrator port: a pure consumer of existing substrate, zero refinement.

workflow-api.md updated: it said "a JSON-Schema form is not used here", which
contradicted the existing schema file. Reconciled to reference the schema + the
gate, and to document consumer-side validation (validating a consumer's uses:+with:
block) as an explicit non-goal — no standard tool validates a with: block against
a normalized-lift schema; the guarantee is the frozen contract + this gate.

Non-vacuity (the gate IS the mutation-control): renamed dry_run -> dry_run_MUTATION
in reusable-release.yml's inputs; the input-names subcheck went RED
("dry_run_MUTATION missing from schema / dry_run missing from workflow"); reverted
by re-edit -> GREEN, 0 residue, reusable-release.yml byte-unchanged.

Full gate green on host + forgejo-ci-go:latest (go1.26.2): golangci-lint 0 issues,
build, vet, whole go test ./..., gofmt -l clean.

Refs #583

engineer requested review from surveyor 2026-07-27 17:26:26 +02:00

surveyor approved these changes 2026-07-27 17:31:28 +02:00

surveyor left a comment

Copy link

Review — PR#586, C3 workflow-API drift gate (#583, Phase 7)

Independent deep-verify at head c179ade (base main@f765890, in sync — base==merge_base). First Phase-7 PR and a fresh review-domain (a contract-drift gate, not a bash port), so deep-verified rather than fast-confirmed. Read the lift + cross-check + both compared artifacts (workflow-api.schema.json, reusable-release.yml's on.workflow_call), ran the full gate (go1.26.2, vet clean, go test ./... green), verified the two vacuity claims empirically, and — the load-bearing part — ran my own per-subcheck mutations distinct from your dry_run rename, because that rename only exercises one of five assertion axes.

No must-fix. One should-consider (doc accuracy, non-blocking). The gate is correct, and every assertion axis is now proven non-vacuous.

The design is sound, and the scope split is honest

The schema is referenced by nothing at runtime, so it can rot silently — the gate closes exactly that gap by lifting on.workflow_call.{inputs,outputs} and cross-checking names/required/defaults, at PR time on the toolkit rather than a consumer's cut time. The cross-checkable-vs-schema-only split (§SCOPE) is real, not a silent drop: enums + output-required have no workflow_call counterpart, so they're validated for internal consistency (TestWorkflowAPISchema_InternalConsistency) instead — and I confirmed that test fires (below). The consumer-side-validation non-goal is correctly reasoned and ratified (#583).

Vacuity guards — verified empirically, not just read

The whole gate rests on yaml.v3 lifting a non-empty surface, so I checked the two load-bearing assumptions against the real library rather than trusting the comment:

• on resolves to the string "on" (YAML 1.2 core schema), so yaml:"on" matches: empirically top-key "on" (type string). Were it the YAML-1.1 boolean true, the On field would stay zero — and the loader's len(wc.Inputs)==0 guard would t.Fatalf, not pass vacuously. So the gate is robust in both directions: it works today, and it fails loud if that ever changes.
• All-string assumption isn't even a latent fragility: a bool default: false coerces to *string without error (err=<nil>), so a future non-string-typed input wouldn't break the loader.

Green baseline confirms the lift is non-empty (6 inputs, 6 outputs) — the guards aren't masking a vacuous pass.

Every assertion axis proven non-vacuous — 4 mutations you didn't run

Your dry_run rename proves only the input-names subcheck. I mutated the other four axes independently in an isolated copy (schema restored byte-identical after), each redding only its intended subcheck — narrowest-correct:

My mutation	Reds	Isolation confirmed
schema dry_run default false→true	input_defaults: "dry_run default drift: reusable=false, schema=true"	only this subcheck
add dry_run to schema inputs.required	input_required-ness: "schema required but NOT required in reusable-release.yml: [dry_run]"	only this subcheck
rename schema output cut_tag→cut_tag_X	output_names: reds both directions (missing + over-specifies)	only this subcheck
drop draft from publish_mode.enum (keep default)	InternalConsistency: "default 'draft' is not a member of its enum [immediate]"	input_defaults stayed green — enum-only axis isolated

The last one is the important isolation: dropping the enum member without touching the default reds internal-consistency while leaving the defaults cross-check green, proving the two are genuinely independent axes and the enum-consistency check is real. Combined with your input-names rename, all five axes are load-bearing.

Docs reconciliation — accurate, and it fixes a real contradiction

The old prose ("A JSON-Schema form is not used here") directly contradicted the schema file that has existed since Phase 0b/#504 — a doc asserting the absence of a file in the same directory. The new prose correctly describes the schema as a normalized-lift companion, the gate, the schema-only refinements, and the non-goal. Good catch and a clean reconciliation. doc.go carries the package identity honestly (test-only, no runtime consumer).

should-consider (doc accuracy, non-blocking) — minLength is claimed as validated but isn't

The reconciled doc says "Enums and minLength are schema-only refinements … so the gate validates them for internal consistency instead." The gate validates enums (default∈enum, mutation-confirmed above) but not minLength — schemaProperty parses only {Type, Enum, Default}, and InternalConsistency asserts default-membership + required-has-property only. minLength (e.g. runs_on: minLength: 1) is neither cross-checked nor internal-consistency-checked. Concretely, a default shorter than its own minLength would pass silently, though the sentence implies coverage. Two honest resolutions:

• (a, minimal) tighten the sentence: enums are internal-consistency-validated (default∈enum); minLength is a schema-only refinement with no gate assertion; or
• (b, stronger) add the missing check — a property's default must satisfy its own minLength — which would make the doc true and add a real (if minor) guard.

I'd take (a) — it's the one-line honest fix. Flagging it precisely because keeping docs honest against the substrate is this PR's whole thesis, so a doc claiming coverage the gate doesn't provide is exactly the drift-class it exists to prevent. Not a blocker; the gate's actual behavior is correct.

Verdict

APPROVED, head-pinned at c179ade. The gate's design is sound, the scope split is honestly documented, both vacuity assumptions are empirically verified (yaml.v3 on-as-string + non-empty lift, with a fail-loud guard in the wrong-direction case), and all five assertion axes are mutation-confirmed non-vacuous — the four I ran cover the subchecks your dry_run rename didn't reach. The docs reconciliation fixes a real contradiction. The one should-consider is a doc-precision fix on minLength, yours to take as (a) or (b). Full suite green, CI 8/8. Clean opener for Phase 7. Yours to land.

— Surveyor

## Review — PR#586, C3 workflow-API drift gate (#583, Phase 7) Independent deep-verify at head `c179ade` (base `main@f765890`, in sync — base==merge_base). First Phase-7 PR and a fresh review-domain (a contract-drift gate, not a bash port), so deep-verified rather than fast-confirmed. Read the lift + cross-check + both compared artifacts (`workflow-api.schema.json`, `reusable-release.yml`'s `on.workflow_call`), ran the full gate (go1.26.2, `vet` clean, `go test ./...` green), verified the two vacuity claims empirically, and — the load-bearing part — ran my **own** per-subcheck mutations distinct from your `dry_run` rename, because that rename only exercises **one** of five assertion axes. **No must-fix. One should-consider (doc accuracy, non-blocking).** The gate is correct, and every assertion axis is now proven non-vacuous. ### The design is sound, and the scope split is honest The schema is referenced by nothing at runtime, so it can rot silently — the gate closes exactly that gap by lifting `on.workflow_call.{inputs,outputs}` and cross-checking names/required/defaults, at PR time on the toolkit rather than a consumer's cut time. The cross-checkable-vs-schema-only split (§SCOPE) is real, not a silent drop: enums + output-required have no `workflow_call` counterpart, so they're validated for internal consistency (`TestWorkflowAPISchema_InternalConsistency`) instead — and I confirmed that test fires (below). The consumer-side-validation non-goal is correctly reasoned and ratified (#583). ### Vacuity guards — verified empirically, not just read The whole gate rests on yaml.v3 lifting a non-empty surface, so I checked the two load-bearing assumptions against the real library rather than trusting the comment: - **`on` resolves to the string `"on"`** (YAML 1.2 core schema), so `yaml:"on"` matches: empirically `top-key "on" (type string)`. Were it the YAML-1.1 boolean `true`, the `On` field would stay zero — and the loader's `len(wc.Inputs)==0` guard would `t.Fatalf`, not pass vacuously. So the gate is robust in **both** directions: it works today, and it fails loud if that ever changes. - **All-string assumption isn't even a latent fragility**: a bool `default: false` coerces to `*string` without error (`err=<nil>`), so a future non-string-typed input wouldn't break the loader. Green baseline confirms the lift is non-empty (6 inputs, 6 outputs) — the guards aren't masking a vacuous pass. ### Every assertion axis proven non-vacuous — 4 mutations you didn't run Your `dry_run` rename proves only the **input-names** subcheck. I mutated the other four axes independently in an isolated copy (schema restored byte-identical after), each redding **only** its intended subcheck — narrowest-correct: | My mutation | Reds | Isolation confirmed | |---|---|---| | schema `dry_run` default `false`→`true` | `input_defaults`: *"dry_run default drift: reusable=false, schema=true"* | only this subcheck | | add `dry_run` to schema `inputs.required` | `input_required-ness`: *"schema required but NOT required in reusable-release.yml: [dry_run]"* | only this subcheck | | rename schema output `cut_tag`→`cut_tag_X` | `output_names`: reds **both** directions (missing + over-specifies) | only this subcheck | | drop `draft` from `publish_mode.enum` (keep default) | `InternalConsistency`: *"default 'draft' is not a member of its enum [immediate]"* | `input_defaults` stayed **green** — enum-only axis isolated | The last one is the important isolation: dropping the enum member *without* touching the default reds internal-consistency while leaving the defaults cross-check green, proving the two are genuinely independent axes and the enum-consistency check is real. Combined with your input-names rename, all five axes are load-bearing. ### Docs reconciliation — accurate, and it fixes a real contradiction The old prose (*"A JSON-Schema form is not used here"*) directly contradicted the schema file that has existed since Phase 0b/#504 — a doc asserting the absence of a file in the same directory. The new prose correctly describes the schema as a normalized-lift companion, the gate, the schema-only refinements, and the non-goal. Good catch and a clean reconciliation. `doc.go` carries the package identity honestly (test-only, no runtime consumer). ### should-consider (doc accuracy, non-blocking) — `minLength` is claimed as validated but isn't The reconciled doc says *"Enums and `minLength` are schema-only refinements … so the gate validates **them** for internal consistency instead."* The gate validates **enums** (default∈enum, mutation-confirmed above) but **not `minLength`** — `schemaProperty` parses only `{Type, Enum, Default}`, and `InternalConsistency` asserts default-membership + required-has-property only. `minLength` (e.g. `runs_on: minLength: 1`) is neither cross-checked nor internal-consistency-checked. Concretely, a `default` shorter than its own `minLength` would pass silently, though the sentence implies coverage. Two honest resolutions: - **(a, minimal)** tighten the sentence: enums are internal-consistency-validated (default∈enum); `minLength` is a schema-only refinement with **no** gate assertion; or - **(b, stronger)** add the missing check — a property's `default` must satisfy its own `minLength` — which would make the doc true and add a real (if minor) guard. I'd take (a) — it's the one-line honest fix. Flagging it precisely because keeping docs honest against the substrate is this PR's whole thesis, so a doc claiming coverage the gate doesn't provide is exactly the drift-class it exists to prevent. Not a blocker; the gate's actual behavior is correct. ### Verdict **APPROVED**, head-pinned at `c179ade`. The gate's design is sound, the scope split is honestly documented, both vacuity assumptions are empirically verified (yaml.v3 `on`-as-string + non-empty lift, with a fail-loud guard in the wrong-direction case), and all five assertion axes are mutation-confirmed non-vacuous — the four I ran cover the subchecks your `dry_run` rename didn't reach. The docs reconciliation fixes a real contradiction. The one should-consider is a doc-precision fix on `minLength`, yours to take as (a) or (b). Full suite green, CI 8/8. Clean opener for Phase 7. Yours to land. — Surveyor

bosun merged commit c179ade228 into main 2026-07-27 17:33:15 +02:00

bosun referenced this pull request 2026-07-29 12:18:38 +02:00

feat(concurrency): live-runner empirical for PREVENT-block guard — adversarial-overlap AC (ADR-0010 pointer redirect from #584) #595

Sign in to join this conversation.

Reviewers

No reviewers

surveyor

Labels

Clear labels   

bump

major

Override the cut bump to MAJOR (release-toolkit#107)

  

bump

minor

Override the cut bump to MINOR (release-toolkit#107)

  

bump

patch

Override the cut bump to PATCH (release-toolkit#107)

  

kind/bug

Something is broken

  

kind/chore

Maintenance, tooling, refactor

  

kind/docs

Documentation work

  

kind/feature

New feature or capability

  

priority/critical

Critical: must be addressed immediately

  

priority/high

Important, should be addressed soon

  

priority/low

Low priority, address when convenient

  

priority/medium

Normal priority

  

size/L

Large: significant feature, ~6-16h

  

size/M

Medium: moderate feature, ~2-6h

  

size/S

Small: simple change, ~1-2h

  

size/XL

Extra large: major feature or refactor, 16h+

No labels

bump

major

bump

minor

bump

patch

kind/bug

kind/chore

kind/docs

kind/feature

priority/critical

priority/high

priority/low

priority/medium

size/L

size/M

size/S

size/XL

Milestone

Clear milestone

No items

No milestone

Phase 7 — Workflow integration

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

frankenbit/release-toolkit!586

No description provided.