Repair production automation truth and schedule cleanup
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
Build and Publish Container Image / build-and-push (push) Successful in 18s

This commit is contained in:
tegwick 2026-08-20 11:20:23 +02:00
parent 8bcb416285
commit 944fd158de
19 changed files with 441 additions and 64 deletions

View file

@ -47,12 +47,13 @@ data:
id: "e274defb-28f2-571e-abcb-c17b57eab473"
name: "RMASTER-WP-0020 OpenBao Retention Closeout"
type: activity-definition
version: "1.0"
enabled: true
version: "1.1"
enabled: false
owner: railiance-master
governance: custodian
status: active
status: paused
created: "2026-08-04"
updated: "2026-08-20"
trigger:
type: scheduled
at: "2026-08-17T08:00:00+02:00"
@ -61,7 +62,11 @@ data:
# RMASTER-WP-0020 OpenBao retention closeout
Emits a claimable ops run after the 14-day retention window. It never
The one-shot fired on 2026-08-17 and is now disabled so schedule sync does
not continually try to recreate a completed Temporal schedule. Its open
ops run remains operator-visible, but is intentionally not labelled
`automated`: railiance01 has neither a railiance-master checkout nor the
Claude CLI required by rein-aharness's agent-session approach. It never
deletes retained CoulombCore resources automatically.
```rule
@ -250,13 +255,13 @@ data:
id: "b8e4f1a2-3c6d-4e9f-a1b2-7d8e9f0a1b2c"
name: "Daily TODO.md Stale Review"
type: activity-definition
version: "1.1"
version: "1.2"
enabled: false
owner: custodian
governance: custodian
status: paused
created: "2026-07-08"
updated: "2026-07-20"
updated: "2026-08-20"
trigger:
type: cron
cron_expression: "30 8 * * *"
@ -277,27 +282,26 @@ data:
# Daily TODO.md Stale Review
> **Paused 2026-07-20.** The matched rule below always produces a
> `TaskSpec` (`rules/actions.py::_task_spec_for_rule`), which
> `RunActivityWorkflow` unconditionally routes through `emit_tasks` →
> the deployment-wide `IssueSink` (`ISSUE_SINK_TYPE`, default `rest` →
> issue-core → Forgejo). There is no per-activity sink override in the
> current schema, and this activity is the fleet's *only* consumer of
> `task_template` — it was the sole source of 5 stale-review Forgejo
> issues (`the-custodian` #1#5, opened 2026-07-08, all reviewed and
> closed 2026-07-20). Per current policy, Forgejo issue tracking is not
> the fleet coordination mechanism (binky-control housekeeping session,
> 2026-07-20) — so this activity is disabled (`enabled: false`) rather
> than left to recreate the same sidetrack daily.
> **Paused 2026-07-20; routing note corrected 2026-08-20.** This
> definition was paused after its matched rules created five unexpected
> Forgejo issues (`the-custodian` #1#5). That was the behavior at the
> time, when the deployment-wide `IssueSink` defaulted to `rest` →
> issue-core → Forgejo.
>
> **Re-enable path:** redirect the rule's output onto the work-record
> backbone (`work-record-types_v0.1.md`, `kind: intake` — "a stale TODO.md
> is exactly a finding/directive") instead of `IssueSink`. This needs
> either a new report-sink type in activity-core (file-based intake-item
> authoring in the target repo, mirroring `state-hub-progress`) or routing
> through the stage-3 promotion tooling seeded in `CUST-WP-0060`'s closure
> review (item 6, added 2026-07-20). Do not re-enable with `enabled: true`
> alone; that only restores the Forgejo-issue behavior.
> ACTIVITY-WP-0022 subsequently changed the fleet and code default to
> `ISSUE_SINK_TYPE=state-hub`. A matched rule now emits an
> `activity_task_spawn` progress event (and, when the ops-run queue is
> enabled, a claimable `ops_run`); it does **not** create a Forgejo issue
> unless an operator explicitly opts the deployment into
> `ISSUE_SINK_TYPE=rest`.
>
> **Current state:** `enabled: false` is retained so this documentation
> correction does not silently restore a production cadence. Before
> re-enabling, the owner should confirm that one task per stale repo per
> daily run is the intended fan-out and that the ops-run consumer will
> claim it. If that is the intended behavior, changing `enabled: true` is
> sufficient; no new sink type is required. State Hub progress remains
> visibility evidence, not claim authority.
>
> This file change is the ADR-001 source of truth; the live activity-core
> DB row picks it up on the next `make sync-activity-definitions` run
@ -331,12 +335,13 @@ data:
id: "f3a8c2e1-9b4d-4a6f-8e2d-1c5b7a9e3f04"
name: "Phase 5 Stabilization Daily Check"
type: activity-definition
version: "1.0"
enabled: true
version: "1.1"
enabled: false
owner: custodian
governance: custodian
status: active
status: paused
created: "2026-07-06"
updated: "2026-08-20"
trigger:
type: cron
cron_expression: "0 9 * * *"
@ -367,6 +372,9 @@ data:
---
# ActivityDefinition: Phase 5 Stabilization Daily Check
Disabled after review on 2026-08-20: its fixed stabilization window ended
on 2026-07-09 and the referenced State Hub task/workstream no longer exists.
weekly-legacy-meter-review.md: |
---
id: weekly-legacy-meter-review
@ -442,12 +450,13 @@ data:
id: "e7d2b5a8-4c1f-4e9a-b6d3-8f2a1c4e6b09"
name: "Phase 5 Stabilization Closeout Check"
type: activity-definition
version: "1.0"
enabled: true
version: "1.1"
enabled: false
owner: custodian
governance: custodian
status: active
status: paused
created: "2026-07-06"
updated: "2026-08-20"
trigger:
type: scheduled
at: "2026-07-09T17:35:00+00:00"
@ -477,17 +486,21 @@ data:
---
# ActivityDefinition: Phase 5 Stabilization Closeout Check
The one-shot fire date passed on 2026-07-09. Keep this disabled so schedule
sync does not retry a completed Temporal schedule.
core-hub-stabilization-daily.md: |
---
id: "b4c8e2f1-6a3d-4e5b-9f0c-2d7e8a1b3c4d"
name: "Core Hub Stabilization Daily Check"
type: activity-definition
version: "1.0"
enabled: true
version: "1.1"
enabled: false
owner: core-hub
governance: core-hub
status: active
status: paused
created: "2026-07-07"
updated: "2026-08-20"
trigger:
type: cron
cron_expression: "0 9 * * *"
@ -514,17 +527,21 @@ data:
---
# ActivityDefinition: Core Hub Stabilization Daily Check
Disabled after review on 2026-08-20: the fixed evidence window ended on
2026-07-10 and CORE-WP-0007 is finished and archived.
core-hub-stabilization-closeout.md: |
---
id: "c5d9f3a2-7b4e-5f6c-0a1d-3e8f9b2c4d5e"
name: "Core Hub Stabilization Closeout Check"
type: activity-definition
version: "1.0"
enabled: true
version: "1.1"
enabled: false
owner: core-hub
governance: core-hub
status: active
status: paused
created: "2026-07-07"
updated: "2026-08-20"
trigger:
type: scheduled
at: "2026-07-10T17:35:00+00:00"
@ -550,6 +567,9 @@ data:
---
# ActivityDefinition: Core Hub Stabilization Closeout Check
The one-shot fire date passed on 2026-07-10. Keep this disabled so schedule
sync does not retry a completed Temporal schedule.
ops-service-inventory-probes.md: |
---
id: "40d15a87-7ff6-4d8e-992c-37df15f95110"