HOMELAB-2682: chore(tooling): relief threshold 55->30, phase1 (GITS+Lab) only #880

Merged
pi-landing merged 1 commit from plane/HOMELAB-2682-relief-threshold-p1 into live 2026-11-06 20:50:01 +00:00
Collaborator

What ships

The relief threshold for the GITS and Lab sandboxes only: RELIEF_THRESHOLD
defaults to 30 (was 55). Three files, all under
core/manifests/apps/sbx-common-phase1/:

file change
epic-supervisor.wait-orchestrator.sh RELIEF_THRESHOLD="${RELIEF_THRESHOLD:-30}", the CONTEXTO check compares against it, header text updated
epic-supervisor.SKILL.md §5 CONTEXTO and §6 relief say RELIEF_THRESHOLD (30 % by default); one line in §6 naming the single setting; reglas.md added to the §0 start-up reading list
SHA256SUMS the two changed phase1 files only — every other line byte-identical

Nothing else. No new mechanism, no new variable: it is the same single setting
under the same name in every copy of the wait.

Deliberately excluded (and why)

  • sbx-common/ (the Spanish supervisor-epica.SKILL.md +
    supervisor-epica.espera-orq.sh + its SHA256SUMS)
    — those bytes are what
    sbx-sendrast runs. The ruling: Sendrast stays at 55. There is no PR B;
    /opt/sendrast-director is untouched.
  • sbx-gits/reglas-fijas.md — the added section was ruled the wrong file:
    its hunk breaks the 60-line cap and 17[R159](d). The single-setting note
    belongs in epic-supervisor §6, which is where it now is.

Closing condition: sbx-sendrast renders byte-identical (proof)

El Director's condition is that the sendrast render does not change at all,
byte for byte — not merely that no pod rolls.

commit kubectl kustomize core/manifests/apps/sbx-sendrast sha256
base (origin/live) 8ea98ed85770700a92ad333431d9d7f3b138cf37 d225759f534949db66b0cf066581d3a9c6f74f59ae2b4e10068b1429f736271a
head (this PR) 21dff84ce00280b4e13de163e4d804c32bf5df98 d225759f534949db66b0cf066581d3a9c6f74f59ae2b4e10068b1429f736271a

kubectl kustomize, no flags (what ArgoCD does), each tree rendering with
its own ../sbx-common Component: both exit 0, 2191 lines, cmp 0,
diff -u empty.

Two controls show the comparison is not vacuous:

  • #878 as it stood (80cd9eb598cdc057d9ea7503b5516ae13666c97b) renders
    sendrast as 955f1aab250dcc365cf209ae3696ac2345a782db48d9b23003c91bb3df1063a1
    — different from base (the sbx-common pair changing the sha256sums
    ConfigMap and the Spanish skill text). That is exactly the reach this PR drops.
  • This PR's change does render: sbx-lab moves from
    65b5ecb6095c41d832ce573de79649c53720847ae6a166462e403f2d5eb7863c
    (base) to 9a685456e7aa52ccf0dcc167aefd795a07e0ebd4b7f8675d3c38f1c0cda8e218
    (head), 23 changed lines — the phase1 ConfigMap the GITS+Lab sandboxes consume
    is the one that moved.

Evidence (renders, diff, controls, README with the commands to reproduce):
working-files/ldv0/homelab-2682-prA-render-proof/ on the mgmt VM.

Verification run locally

  • sha256sum -c SHA256SUMS in core/manifests/apps/sbx-common-phase1: all 15
    entries OK
  • bash -n epic-supervisor.wait-orchestrator.sh: clean
  • shellcheck: one pre-existing SC2034 (PLANE_TOKEN unused) — identical at
    base, untouched by this PR
  • grep -n '\b55\b' over both phase1 files: no match
  • git diff origin/live...HEAD --stat: exactly the 3 files above

Operational note

ConfigMap data only; the StatefulSets are OnDelete, so nothing rolls. The
pods pick the new threshold up at their next restart, and until that restart
the in-pod SHA256SUMS check in sbx-lab goes RED on sync because the mounted
SHA256SUMS refreshes in place while the skills files do not. Accepted, and
recorded so homelab-33 and homelab-73 know before landing.

Closes nothing by itself: #878 is superseded by this PR and is to be closed
unmerged.

## What ships The relief threshold for the **GITS and Lab** sandboxes only: `RELIEF_THRESHOLD` defaults to **30** (was 55). Three files, all under `core/manifests/apps/sbx-common-phase1/`: | file | change | |---|---| | `epic-supervisor.wait-orchestrator.sh` | `RELIEF_THRESHOLD="${RELIEF_THRESHOLD:-30}"`, the `CONTEXTO` check compares against it, header text updated | | `epic-supervisor.SKILL.md` | §5 `CONTEXTO` and §6 relief say `RELIEF_THRESHOLD` (30 % by default); one line in §6 naming the single setting; `reglas.md` added to the §0 start-up reading list | | `SHA256SUMS` | the two changed phase1 files only — every other line byte-identical | Nothing else. No new mechanism, no new variable: it is the same single setting under the same name in every copy of the wait. ## Deliberately excluded (and why) - **`sbx-common/` (the Spanish `supervisor-epica.SKILL.md` + `supervisor-epica.espera-orq.sh` + its `SHA256SUMS`)** — those bytes are what `sbx-sendrast` runs. The ruling: **Sendrast stays at 55**. There is no PR B; `/opt/sendrast-director` is untouched. - **`sbx-gits/reglas-fijas.md`** — the added section was ruled the wrong file: its hunk breaks the 60-line cap and `17[R159](d)`. The single-setting note belongs in `epic-supervisor` §6, which is where it now is. ## Closing condition: `sbx-sendrast` renders byte-identical (proof) El Director's condition is that the sendrast render does not change at all, byte for byte — not merely that no pod rolls. | | commit | `kubectl kustomize core/manifests/apps/sbx-sendrast` sha256 | |---|---|---| | base (`origin/live`) | `8ea98ed85770700a92ad333431d9d7f3b138cf37` | `d225759f534949db66b0cf066581d3a9c6f74f59ae2b4e10068b1429f736271a` | | head (this PR) | `21dff84ce00280b4e13de163e4d804c32bf5df98` | `d225759f534949db66b0cf066581d3a9c6f74f59ae2b4e10068b1429f736271a` | `kubectl kustomize`, **no flags** (what ArgoCD does), each tree rendering with its own `../sbx-common` Component: both exit 0, 2191 lines, `cmp` 0, `diff -u` empty. Two controls show the comparison is not vacuous: - **#878 as it stood** (`80cd9eb598cdc057d9ea7503b5516ae13666c97b`) renders sendrast as `955f1aab250dcc365cf209ae3696ac2345a782db48d9b23003c91bb3df1063a1` — different from base (the `sbx-common` pair changing the `sha256sums` ConfigMap and the Spanish skill text). That is exactly the reach this PR drops. - **This PR's change does render**: `sbx-lab` moves from `65b5ecb6095c41d832ce573de79649c53720847ae6a166462e403f2d5eb7863c` (base) to `9a685456e7aa52ccf0dcc167aefd795a07e0ebd4b7f8675d3c38f1c0cda8e218` (head), 23 changed lines — the phase1 ConfigMap the GITS+Lab sandboxes consume is the one that moved. Evidence (renders, diff, controls, README with the commands to reproduce): `working-files/ldv0/homelab-2682-prA-render-proof/` on the mgmt VM. ## Verification run locally - `sha256sum -c SHA256SUMS` in `core/manifests/apps/sbx-common-phase1`: all 15 entries **OK** - `bash -n epic-supervisor.wait-orchestrator.sh`: clean - `shellcheck`: one **pre-existing** SC2034 (`PLANE_TOKEN` unused) — identical at base, untouched by this PR - `grep -n '\b55\b'` over both phase1 files: **no match** - `git diff origin/live...HEAD --stat`: exactly the 3 files above ## Operational note ConfigMap data only; the StatefulSets are `OnDelete`, so **nothing rolls**. The pods pick the new threshold up at their **next restart**, and until that restart the in-pod `SHA256SUMS` check in `sbx-lab` goes RED on sync because the mounted `SHA256SUMS` refreshes in place while the skills files do not. Accepted, and recorded so homelab-33 and homelab-73 know before landing. Closes nothing by itself: #878 is superseded by this PR and is to be closed unmerged.
HOMELAB-2682: chore(tooling): relief threshold 55->30, phase1 (GITS+Lab) only
All checks were successful
CI Review / runner-manifest-test (pull_request) Successful in 6s
CI Review / receiver-test (pull_request) Successful in 6s
CI Review / helm-validate (pull_request) Successful in 13s
Lint & Validate / shellcheck (pull_request) Successful in 6s
CI Review / alert-receiver-test (pull_request) Successful in 22s
Lint & Validate / yaml-lint (pull_request) Successful in 24s
CI Review / record-sql-test (pull_request) Successful in 50s
Lint & Validate / terraform-validate (pull_request) Successful in 2m19s
CI Review / cockpit-test (pull_request) Successful in 2m29s
CI Review / cockpit-e2e (pull_request) Successful in 2m43s
CI Review / dispatcher-test (pull_request) Successful in 3m25s
21dff84ce0
One setting, RELIEF_THRESHOLD, default 30, in the GITS+Lab copies only.

- sbx-common-phase1/epic-supervisor.wait-orchestrator.sh: RELIEF_THRESHOLD=30
  (default), the CONTEXTO check compares against it, header text updated
- sbx-common-phase1/epic-supervisor.SKILL.md: §5 CONTEXTO and §6 relief say
  RELIEF_THRESHOLD (30 % by default), one line in §6 naming the single setting,
  reglas.md added to the §0 start-up reading list
- sbx-common-phase1/SHA256SUMS: the two changed phase1 files only

Deliberately NOT here: sbx-common (supervisor-epica pair + its SHA256SUMS) --
those bytes are what sbx-sendrast runs and the ruling keeps Sendrast at 55 --
and sbx-gits/reglas-fijas.md (wrong file: its hunk breaks the 60-line cap and
17[R159](d)). sbx-sendrast's render is byte-identical at base and head.
Collaborator

Verdict of record — ld-reviewer — head 21dff84ce0: APPROVE
model: omniroute/deepseek-flash
session: 01a1b28d-9e26-7155-8e66-42819d527083

Blockers

None.

What I measured

I worked from git objects only: a throwaway read-only clone, git diff 8ea98ed8..21dff84c, two detached worktrees (base and head), and my own kubectl kustomize render of core/manifests/apps/sbx-sendrast at each side.

Check Measurement Result
Files touched 3, all under core/manifests/apps/sbx-common-phase1/: SHA256SUMS, epic-supervisor.SKILL.md, epic-supervisor.wait-orchestrator.sh phase1-only holds
sbx-common bytes tree sha fc3fff5be372634a7835b98513cd6c550e472af2 at base and at head identical
sbx-gits bytes (incl. reglas-fijas.md) tree sha 73009b2cc6982555cb42998297c380823f32006f at base and at head identical
Threshold 55→30 RELIEF_THRESHOLD="${RELIEF_THRESHOLD:-30}" (wait script L113); comparison [ "${pct%.*}" -ge "$RELIEF_THRESHOLD" ] (L200); 0 bare 55 left anywhere in phase1 holds
§0 start-up reading list L43 head: Read \intent.md`, `operator-words.md`, `reglas.md`, `decisiones.md`, `status.md` and `sup-handoff.md` if it exists.` reglas.md present
phase1 SHA256SUMS internal consistency sha256sum -c at head: 15/15 OK; at base: 15/15 OK; diff base→head is exactly lines 3–4 (the two edited files). New entries 0052cdce… and bb80172b… match the tree. consistent
Sendrast closing condition render sha256 base d225759f534949db66b0cf066581d3a9c6f74f59ae2b4e10068b1429f736271a, head d225759f534949db66b0cf066581d3a9c6f74f59ae2b4e10068b1429f736271a; cmp exit 0 byte-identical
Negative control on that render the head render carries sbx-common's Spanish pair verbatim — 8 occurrences of 55 (incl. ≥ 55 % and -ge 55) and 0 occurrences of RELIEF_THRESHOLD, plus the sbx-skills-source component ConfigMap the render really depends on sbx-common, so base==head is evidence, not vacuous
Shell syntax bash -n OK at head and at base; sh -n fails at L72 on both sides (pre-existing: the script is #!/usr/bin/env bash and uses arrays) no regression
Repo's own test assumptions scripts/gits-sbx-epic-test.sh pins no 55 for phase1, asserts sbx-sendrast/kustomization.yaml does not pull phase1 (L11354) untouched, nothing contradicted

Judgement

Correctness: the diff does exactly what the ruling asks, and nothing else. The setting is one variable under one name, its default moved 55→30, the comparison reads the variable, and the two prose mentions in §2 and §6 now name it rather than restating a number, so the doc cannot drift from the script again.

Completeness: the three artefacts a settings change needs are all present — the script, the skill prose that describes it, and the regenerated SHA256SUMS limited to the two edited files.

Claim honesty: the commit message says sbx-sendrast's render is byte-identical at base and head, and my own re-derivation reproduces that exactly. It also says sbx-common and sbx-gits/reglas-fijas.md are deliberately absent, and both trees hash the same on both sides. The §6 sentence claiming the name is shared by "§2 and wait-orchestrator.sh" is accurate — §2 does carry the identifier (L236).

Non-blocking notes, for whoever reads this next:

  • kustomization.yaml is absent from the phase1 SHA256SUMS list. That is the same on base and head, so this PR neither introduces nor worsens it.
  • The two new §6 lines sit between the bolded rule line and the numbered list with no blank line. CommonMark lets a 1. list interrupt a paragraph, so the list still renders; cosmetic only.
  • The comparison is an integer -ge test, so a fractional override such as 30.5 would make the test error out rather than compare. Not a problem for the documented default.
Verdict of record — ld-reviewer — head 21dff84ce00280b4e13de163e4d804c32bf5df98: APPROVE model: omniroute/deepseek-flash session: 01a1b28d-9e26-7155-8e66-42819d527083 ## Blockers None. ## What I measured I worked from git objects only: a throwaway read-only clone, `git diff 8ea98ed8..21dff84c`, two detached worktrees (base and head), and my own `kubectl kustomize` render of `core/manifests/apps/sbx-sendrast` at each side. | Check | Measurement | Result | |---|---|---| | Files touched | 3, all under `core/manifests/apps/sbx-common-phase1/`: `SHA256SUMS`, `epic-supervisor.SKILL.md`, `epic-supervisor.wait-orchestrator.sh` | phase1-only holds | | `sbx-common` bytes | tree sha `fc3fff5be372634a7835b98513cd6c550e472af2` at base and at head | identical | | `sbx-gits` bytes (incl. `reglas-fijas.md`) | tree sha `73009b2cc6982555cb42998297c380823f32006f` at base and at head | identical | | Threshold 55→30 | `RELIEF_THRESHOLD="${RELIEF_THRESHOLD:-30}"` (wait script L113); comparison `[ "${pct%.*}" -ge "$RELIEF_THRESHOLD" ]` (L200); 0 bare `55` left anywhere in phase1 | holds | | §0 start-up reading list | L43 head: `Read \`intent.md\`, \`operator-words.md\`, \`reglas.md\`, \`decisiones.md\`, \`status.md\` and \`sup-handoff.md\` if it exists.` | `reglas.md` present | | phase1 `SHA256SUMS` internal consistency | `sha256sum -c` at head: 15/15 OK; at base: 15/15 OK; diff base→head is exactly lines 3–4 (the two edited files). New entries `0052cdce…` and `bb80172b…` match the tree. | consistent | | **Sendrast closing condition** | render sha256 base `d225759f534949db66b0cf066581d3a9c6f74f59ae2b4e10068b1429f736271a`, head `d225759f534949db66b0cf066581d3a9c6f74f59ae2b4e10068b1429f736271a`; `cmp` exit 0 | byte-identical | | Negative control on that render | the head render carries `sbx-common`'s Spanish pair verbatim — 8 occurrences of `55` (incl. `≥ 55 %` and `-ge 55`) and 0 occurrences of `RELIEF_THRESHOLD`, plus the `sbx-skills-source` component ConfigMap | the render really depends on `sbx-common`, so base==head is evidence, not vacuous | | Shell syntax | `bash -n` OK at head and at base; `sh -n` fails at L72 on **both** sides (pre-existing: the script is `#!/usr/bin/env bash` and uses arrays) | no regression | | Repo's own test assumptions | `scripts/gits-sbx-epic-test.sh` pins no `55` for phase1, asserts `sbx-sendrast/kustomization.yaml` does not pull phase1 (L11354) | untouched, nothing contradicted | ## Judgement Correctness: the diff does exactly what the ruling asks, and nothing else. The setting is one variable under one name, its default moved 55→30, the comparison reads the variable, and the two prose mentions in §2 and §6 now name it rather than restating a number, so the doc cannot drift from the script again. Completeness: the three artefacts a settings change needs are all present — the script, the skill prose that describes it, and the regenerated `SHA256SUMS` limited to the two edited files. Claim honesty: the commit message says `sbx-sendrast`'s render is byte-identical at base and head, and my own re-derivation reproduces that exactly. It also says `sbx-common` and `sbx-gits/reglas-fijas.md` are deliberately absent, and both trees hash the same on both sides. The §6 sentence claiming the name is shared by "`§2` and `wait-orchestrator.sh`" is accurate — §2 does carry the identifier (L236). Non-blocking notes, for whoever reads this next: - `kustomization.yaml` is absent from the phase1 `SHA256SUMS` list. That is the same on base and head, so this PR neither introduces nor worsens it. - The two new §6 lines sit between the bolded rule line and the numbered list with no blank line. CommonMark lets a `1.` list interrupt a paragraph, so the list still renders; cosmetic only. - The comparison is an integer `-ge` test, so a fractional override such as `30.5` would make the test error out rather than compare. Not a problem for the documented default.
Sign in to join this conversation.
No reviewers
No labels
operator-review
No milestone
No project
No assignees
2 participants
Notifications
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
Homelab/infra-core!880
No description provided.