coulomb/activity-core
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Accept ACT-ADR-005 and open ACTIVITY-WP-0026 for ops_run claim queue.
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 2s
Details

Browse source 
Split ops runs (claimable DB) from development work records (repo + State Hub),
ban default Forgejo queueing for automation, and stack WP-0026 with rein-aharness
and issue-core follow-ups. Forgejo-only forge language; no Gitea product path.
This commit is contained in:
tegwick 2026-08-03 18:51:37 +02:00
parent 747d63a993
commit d1e24348c3
4 changed files with 422 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

28
docs/recurring-automations-playbook.md
View file

@ -1,11 +1,17 @@
# Recurring automations playbook — activity-core as the organizer
**Audience:** operators and coding agents adding or fixing recurring work
**Principle:** activity-core answers **when / what / where** only. It does **not** execute.
**Principle:** activity-core answers **when / what / where** only. It does **not** execute.
**Architecture decision:** [ACT-ADR-005](adr/adr-005-ops-runs-vs-dev-work-records.md) —
ops runs (claimable DB) vs development work records (repo files + State Hub).
**Implementation stack:** ACTIVITY-WP-0026 · REIN-A-0002 · ISSUE-WP-0006 · STATE-WP-0078.
This is the org standard. Prefer this path over workstation cron, ad-hoc shell
timers, or “I’ll remember to run it.”
**Self-hosted forge:** **Forgejo** only (not Gitea). External tickets via
issue-core projection — never as the default ops claim queue.
---
## The three layers (do not collapse them)
@ -86,15 +92,19 @@ kubectl -n activity-core exec deploy/actcore-worker -- python3 -c '...' # descr
Ops UI: `activity.coulomb.social` → automations status / trigger (SSO).
### C. Executor (rein-aharness)
### C. Executor (rein-aharness) — target vs interim
1. Prefer a **named rein-aharness command** for the domain work
(e.g. `brief-daily`, `fi-research-brief`) using **llm-connect**, not Claude CLI on railiance01
2. Install **railiance user-systemd timer** in the domain repo
(`scripts/railiance-rhythm/`) that calls rein-aharness
3. Timer should sit **just after** the activity-core cron (due check already
enforced by completion events on re-run)
4. On success, post the **domain completion event** so the resolver sets `due=false`
**Target (ACT-ADR-005 / REIN-A-0002):** continuous **claim loop** on
`ops_run` rows from activity-core; approach table selects adapter
(`fi-research-brief`, `brief-daily`, mail-scan, …).
**Interim (until WP-0026 + REIN-A-0002 cutover):** railiance user-systemd
timer may call rein-aharness wall-clock — **break-glass / dual-clock**, not
cadence authority.
1. Prefer a **named rein-aharness command** + **llm-connect**, not Claude CLI on railiance01
2. On success, post the **domain completion event** so the resolver sets `due=false`
3. Close the **ops_run** (when claim queue is live)
### D. Prove the loop