Create the half-state patrol anchor issue and set the HALF_STATE_ANCHOR_ISSUE repository variable #242

Ruled: 5989574922 · letter A · 2026-10-05T06:52Z
Maintainer-action: open an issue with no labels in this repository as the patrol anchor, and set the repository variable HALF_STATE_ANCHOR_ISSUE to its number — done when a scheduled Half-State Patrol run passes the "Resolve the anchor issue" step

Filed by the repo:objectos seat (objectstack#9831) at the ACCEPT of PR #237 (#165). The decision is made and the code has landed — the only remaining action is a GitHub-settings operation no agent can perform, which is what pm:awaiting-maintainer means. Nothing here is waiting on engineering.

#165 is closed correctly: its title task (install the patrol) is delivered and verified. This card carries the operational step that card flagged as a manual maintainer action from the start.

What is needed, exactly two things

1. Open an issue in this repo to serve as the patrol's pinned anchor. Its body is owned and rewritten in place by the workflow on every run, so it needs no content — a title is enough (e.g. "Half-state patrol — objectos").
2. Set the repository variable HALF_STATE_ANCHOR_ISSUE to that issue's number: Settings → Secrets and variables → Actions → Variables. A variable, not a secret.

⚠️ Create the anchor with NO labels

The upstream recipe says to use a tracking-labelled issue. This repo has no tracking label (24 labels, confirmed via the API), so that instruction cannot be followed literally.

It is not load-bearing: tracking is consulted by exactly one predicate (H13_EXEMPT_LABELS), and H13 only fires on a card carrying a domain:* label with no pm-state label. An unlabelled anchor is safe from every predicate, so the simplest correct answer is to create it bare and skip the label question entirely.

⛔ Do not give the anchor domain:docs to make it look triaged. This repo does carry that label, so the H13 population here is non-empty — an anchor labelled domain:docs and nothing else is exactly the shape H13 fires on, and it would appear as a finding in the sweep it hosts, two hours later.

Until the variable is set

A scheduled run fails loudly at "Resolve the anchor issue" with No anchor issue configured for objectstack-ai/objectos. That is designed behaviour, not a defect — the sweep still runs and its findings are preserved in the run summary. PR #237 deliberately added no fallback, no default anchor number and no silent skip, because a patrol that goes quietly green about the wrong board is the failure mode the whole design guards against.

One thing to confirm on the first run

The workflow requests permissions: issues: write. No existing workflow in this repo requests that, so if this repo's default workflow-token permission is read-only, the first scheduled run will fail on the anchor write. That would be a settings issue, not a code defect — check it before anyone treats a red patrol as a bug in the sweeper.

What this unlocks — measured, not projected

The read-only sweep run during PR #237 against this live board reported:

swept 8 open pm-/p0-labeled issue(s), 11 open issue(s) in the unscoped pass, 5 open PR(s) and 120 recently-merged PR(s) in objectstack-ai/objectos — 82 half-state(s) found

Those 82 are real and are invisible today because nothing sweeps this repo. Setting the variable is what turns that one-off measurement into a standing hourly view.

Re-check

gh variable list --repo objectstack-ai/objectos     # is HALF_STATE_ANCHOR_ISSUE set?

Related: #165 (the install), PR #237, objectstack#11217 (the finding that produced the sibling-repo adoption), objectstack PR #11294 (the upstream parameterisation).