mirror of
https://github.com/microsoft/BCQuality.git
synced 2026-10-06 15:16:56 +01:00
Foerste felt-genererede regelforslag i BCQualitys historie: en session
paa en udviklermaskine (ConzeptALGo, 2026-07-03) ramte 404 paa
{BASE}/templates/find-altool.ps1 - setup v16 var merged til main, men
promoten laa efter, saa dokumentets egen stable-sti kunne ikke serveres.
Sessionen verificerede begge grene med curl, naegtede korrekt at falde
tilbage til main (kanaldisciplinen er selve pointen), og udformede
observation, evidens og filnavn selv.
Reglen: fil + reference shipper i samme PR; merge og promote er EEN
operation for reference-introducerende aendringer; forbrugere der
rammer 404 paa en dokumenteret stable-sti rapporterer gabet og omgaar
aldrig kanalen.
Rute: Francis (feltsession) -> Immanuel (denne universalisering) ->
Michael (merge). Promoten der lukkede det konkrete vindue er allerede
koert (stable @ 470524e).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
65 lines
2.8 KiB
Markdown
65 lines
2.8 KiB
Markdown
---
|
|
bc-version: [all]
|
|
domain: architecture
|
|
keywords: [release-process, stable, promote, setup-agent, templates, atomicity, broken-fetch]
|
|
technologies: [al]
|
|
countries: [w1]
|
|
application-area: [all]
|
|
---
|
|
|
|
# Setup docs must not reference files not yet promoted to stable
|
|
|
|
## Description
|
|
|
|
The setup agent and other BCQuality documents fetch artifacts via the
|
|
`stable`-based BASE URLs. When a change that INTRODUCES a reference to a new
|
|
file (e.g. a new template in the Mode B table) is merged to `main` but not
|
|
yet promoted, every consumer in that window follows the document's own
|
|
documented path and gets a 404 — the document instructs a fetch its own
|
|
release channel cannot serve.
|
|
|
|
This happened in practice: setup v16 added a Mode B row fetching
|
|
`{BASE}/templates/find-altool.ps1`; the file existed on `main` only. A
|
|
session on a developer machine (ConzeptALGo, 2026-07-03) hit the 404,
|
|
verified both branches with curl, and — correctly — refused to fall back to
|
|
`main`, since bypassing the vetted channel would defeat its purpose. The
|
|
observation, evidence and this rule's filename come from that session: the
|
|
first field-originated Type B proposal in BCQuality's history.
|
|
|
|
## Rule
|
|
|
|
A change to `curabis-standard.agent.md` (or any consumer-facing document)
|
|
that introduces a reference to a NEW file via a `stable`-based URL must not
|
|
sit merged on `main` without the referenced file being available on
|
|
`stable`. In practice:
|
|
|
|
1. The referenced file and the reference ship in the SAME pull request —
|
|
they cannot drift apart.
|
|
2. The promote follows the merge immediately when a PR introduces new
|
|
artifact references. Merge and promote are one operation for
|
|
reference-introducing changes, not two events with an open-ended window.
|
|
3. Consumers (sessions, Mode B) that hit a 404 on a documented stable path
|
|
report the gap — they never silently fetch from `main` instead. The
|
|
channel discipline outranks the convenience.
|
|
|
|
## What NOT to do
|
|
|
|
- Do not merge a reference-introducing setup change and leave the promote
|
|
"for later" — the window is a live outage for every Mode B run
|
|
- Do not let automation fall back to `main` when `stable` 404s — that
|
|
silently converts the release gate into decoration
|
|
- Do not fix the window by pointing BASE at `main` — the channel is the
|
|
feature; the discipline around it is what needs to hold
|
|
|
|
## Signal to watch for
|
|
|
|
During Mode B or any documented fetch: HTTP 404 on a `stable`-based URL that
|
|
the current setup document itself references. That is always a release-
|
|
process gap, never a consumer error.
|
|
|
|
## Message to developer
|
|
|
|
When a documented stable fetch 404s, report: this file is referenced by the
|
|
current setup document but has not been promoted to stable yet — the
|
|
maintainer must promote (or the reference merged prematurely); continuing
|
|
with a main-fallback is not permitted.
|