ACTIVITY-WP-0032-T02 / ACT-ADR-006. ops_runs grows harness_profile_ref (text,
indexed) and execution_refs (jsonb), migration 0008, threaded through the
emission path, queue projection, and run artefacts.
The important part is the enforcement, not the columns. ACT-ADR-006 says
approach_hint must never override, synthesize, or fall back from an absent or
invalid harness_profile_ref — a silent fallback would reintroduce the
claim-time routing failure of 2026-08-17. resolve_execution_selector never
consults the hint: a malformed ref raises even when a hint is present, and
ACTIVITY_CORE_REQUIRE_HARNESS_PROFILE turns an absent ref into an error once
definitions have migrated.
Validation is structural only, since the glas-harness catalogue is
authoritative and must not be mirrored. Requiring the <id>@<version> pin is
worth doing locally: GlasProfiles.resolve matches an unpinned ref against every
version and refuses it as ambiguous, so the pin converts a late failure into an
emission-time error without knowing any profile id.
Migration verified on real PostgreSQL 16: upgrade, downgrade, re-upgrade, and a
legacy-shaped row still inserts and stays claimable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
glas-harness answered both open questions from ACTIVITY-WP-0032, so T01 is
resolved as option A: the ops_run pull queue stays and carries the versioned
harness_profile_ref plus attribution refs. The claiming executor passes the
request into Glas, which resolves or refuses before sandbox creation. This
changes the execution contract without also changing scheduling topology.
Two answers shaped the plan:
- harness_profile_ref and approach_hint coexist with distinct semantics.
approach_hint must never override, synthesize, or fall back from an absent or
invalid profile ref on governed execution — T02 must enforce that in code.
- The glas-harness catalog is authoritative and must not be mirrored. Glas has
no network validation service today, so emit-time remote validation is not
available.
T03 is corrected accordingly: validate locally and structurally, rely on the
execution-side Glas resolver as the mandatory fail-closed check, and record the
residual gap rather than papering over it with a mirrored catalogue.
Hub decision 147beec6-7fe7-4837-8e3a-4264a240379d.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Tested rather than relayed: OpenRouter answers 'User not found' for the
delivered key, which means no account resolves it — an existing-account key
reissue, not a new account. Ruled out credits (402), model permissions (403),
provider config, and pod health.
Also records a latent delivery defect: the secret carries a trailing newline,
harmless today only because llm_connect/config.py:53 strips it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
scripts/prod_automation_status.sh took a positional since value, so the
Makefile's own `SINCE=sunday` form passed the literal string into timestamptz:
all five sections errored while the run still looked like it produced a report.
Now `SINCE=` is accepted and the value is parsed and normalised to UTC up
front, failing fast with usage and exit 2 instead of five parse errors.
ACTIVITY-WP-0032 plans adoption of the glas-harness contract 1.0 reported in
GLAS-WP-0004. WP-0026 is finished, so this gets its own plan. The motivation is
concrete: ops_run.approach_hint binds at claim time, which produced a failed
run on 2026-08-17 ("no approach matched labels/definition") after it had
already consumed a claim and a lease.
T01 is deliberately blocking: our claim path is pull-based and the Glas
contract is a call, so the invocation shape is an architectural decision, not a
port. Two questions are outstanding with glas-harness.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
llm-connect maps every provider API error onto HTTP 502 and puts the real
cause in the body (llm_connect/server.py::_error_response: error,
provider_status). LLMConnectClient.complete called raise_for_status() and threw
that body away, so a revoked OpenRouter key was indistinguishable from a downed
gateway — four days of production evidence read as "llm-connect is down".
Live check confirms one fault, not two: the llm-connect pod is Running 1/1 with
healthy endpoints, and today's FI/Binky/triage runs still 502 after yesterday's
rollout, matching the sanitized upstream 401 railiance-platform reported.
The client now raises with error, provider_status, provider, model and a
bounded copy of llm-connect's already-sanitized message, under a field
allowlist so no provider blob or key material reaches the run artefact.
Refs ACTIVITY-WP-0031-T01, T03.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Add the sbom-nexus catch_up resolver contract and the daily replacement for
weekly-sbom-staleness, both disabled until CUST-WP-0062-T03 lands.
The weekly check used `for_each: context.repos.repos` and emitted one task per
stale repo — 75 tasks on 2026-08-17 against 111/111 stale repos. The
replacement asks sbom-nexus for only the N oldest-stale repos in one ranked
call and carries no rule block at all, so tasks_spawned is 0 by construction.
- context_resolvers/sbom_nexus.py: source type `sbom-nexus`, query `catch_up`,
GET /sbom/catch-up?limit=N. Read-only; ingest is T02. Limit bounded 1..25 and
the response truncated to it so an over-long reply cannot widen T02's
side-effect.
- activity-definitions/daily-sbom-catchup.md: weekdays 09:15 Berlin, enabled:
false, deterministic sbom_catchup progress sink.
- rules/executor.py: the deterministic report builder only special-cased
context.repos, which would have emitted a contentless progress event for this
definition. _sbom_catchup_report names the selected repos and reads
updated/skipped from context when T02 populates them.
- 17 tests against a test double; no live nexus exists yet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Map every State Hub/core-hub caller to a post-retirement owner. Keep the
15-minute sweep schedule here and point the engine at repo-manager
(State Hub dual-run by default, REPO_MANAGER_URL when present). Publish
GET /execution/semantics and 410 workplan launch routes so State Hub
/execution/* is not re-homed as a task database. T03 still waits on
HUB-WP-0004.
Review ACTIVITY-WP-0029 against info-tech-canon, policy-nexus, and
State Hub retirement: activity-core keeps schedule and ops_run;
repo-manager owns consistency; hub-core owns progress ports.
Mark WP-0026 finished. Refresh INTENT, SCOPE, and repo-boundary.
Bare make lists targets. make install-cli installs the activity tool via uv.
Named activity-core backends live in ~/.config/activity/services.json with
list/add/use/default/which; -s/--service selects one call without changing
the default; --activity-url is a one-shot override.
Ship the activity console script for consumer-repo morning review: list,
status, runs, deliverables, inbox, checkpoint, and ack. Offline-first with
git + local defs; enriches from ops API and State Hub. Multi-source trust
matrix never reports did-not-run when git has the artefact. Adds
target_repo filter on GET /ops/automations.
