Skip to content

Epic: backlog burn-down 2 — bugs, cohort waits, operational conformance #84

Open

Description

@gregoryfoster

The whole open backlog after epic #24, plus the gaps a 2026-10-24 audit found that nothing tracked: host patching never run, a log-priority bug, a sibling's per-host ask, and cohort ports Processor lacks. Done when Tiers 1 and 2 are closed and live, and every Tier 3 line is closed or parked with a trigger.

Order

The operator's rule, verbatim: "Prioritize bugs, issues other repos are waiting on, and operational conformance and stability."

Tiebreaks the coordinator added, numbered so the operator can challenge one:

  1. Live security exposure ranks as a bug. Adopt host patching: needrestart l, posture scheduled, first window #77 sits in Tier 1 for that reason: 60 -security updates pending, including the OpenSSL that processor run links.
  2. A guard goes before what it guards. WARNING and ERROR records reach journald at INFO priority #76 goes before Adopt host patching: needrestart l, posture scheduled, first window #77, because a patch window's post-check reads journald priority. Inside Adopt host patching: needrestart l, posture scheduled, first window #77, needrestart's l mode is committed before the first apt run.
  3. A sibling wait that is only an operator host step (Disable exe-setup.service on co-processor (CannObserv/provisioner#4) #78) runs alongside the code child in flight. It doesn't take the implementer's slot.
  4. In Tier 3, shared files decide the order: the workflow files (see Overlaps). Bundling two children that share a file is offered at that child's gate, never assumed.
  5. A child that needs an operator decision (Lock audit: a weekly finding notifies nobody #75) gets its question one check-in before it is next.

Overrides: none yet.

Boundary decisions

  • Agent-tooling items (context cadence, SocratiCode bumps, the skills roster) are out of this epic unless a sibling asks something of Processor. Proposed 2026-10-24.
  • A cohort practice Processor lacks is Tier 3, unless it is a live exposure (tiebreak 1). Proposed 2026-10-24.
  • Close what is done or superseded. Park ideas, each with a re-entry trigger. Proposed 2026-10-24.

Exit criterion

Tiers 1 and 2 closed and live. Every Tier 3 line closed or parked with a trigger. #54 may stay parked: its trigger is the broker's, not ours.

Verify recipe

  • Gate: CI lint and test, by job, on the merge SHA and on main's tip. uv audit (report-only) runs alongside and is not a gate. Run at creation: green on db8531a, 2026-10-24.
  • Deploy: scripts/deploy.sh, only when the merge touches src/, deploy/, scripts/deploy.sh, pyproject.toml or uv.lock. Proof: /srv/processor/live/REVISION equals the merge, ActiveEnterTimestamp falls after it, NRestarts=0, and the drift check reports ok at its next hourly run.
  • Baseline: uv run pytest -q, no .env sourced: 748 passed, 5 skipped, containment required (Landlock ABI 6), 2026-10-24. The 5 skips are all tests/test_child.py:290, credential paths unreadable to exedev. Compare skips by id.
  • By deliverable:
    • host change: read before and after (systemctl is-enabled, stat, apt list --upgradable);
    • timer: its journal over one period;
    • log change: journalctl -o json PRIORITY on a real record;
    • workflow change: the job's check-run on the merge SHA, plus one scheduled or dispatched run where the trigger is a schedule;
    • docs: git diff against the claim.
  • Cross-repo probes: scan.sh reads with GH_TOKEN, which can't reach CannObserv/cannobserv or CannObserv/provisioner (404). Read those refs by hand with GH_TOKEN_CANNOBSERV and GH_TOKEN_PROVISIONER at each check-in.

Tier 1: bugs and live exposure

Tier 2: other repos waiting on Processor

Tier 3: operational conformance and stability

Waits

Ref Who waits On what Unblock condition
CannObserv/broker#85 us (#54) the broker's Valkey 7.2 window, gated on CannObserv/broker#95 the post-window notice on CannObserv/broker#85
CannObserv/provisioner#16 them, then us provisioner's co-image-base assessment of co-processor (box unticked since 2026-09-29; 2026-10-30 note covers co-provisioner only) an assessment issue filed here, with the owner's approval
CannObserv/cannobserv#559 CannObserv/archiver#353 a cannobserv release, then Processor's co-core bump a co-core tag carrying CannObserv/cannobserv#559
CannObserv/cannobserv#530 us BlobStore.store reports created vs already stored a co-core release carrying it; adopt at the next planned bump
CannObserv/cannobserv#591 us (#87's residual) a SHA256SUMS asset per co-core release: the second channel that closes the pin-time gap the asset exists on a co-core release; then #87's pin procedure reads it
CannObserv/cannobserv#605 us (#87's builder) cannobserv pins its build backend, or publishes the version per release; until then HATCHLING="1.32.4" in scripts/build_wheelhouse.sh is held by hand (filed by #87's thread, operator-approved) a co-core release whose backend is pinned or published; then the bump procedure reads it

Parked

Ref Re-entry trigger Last re-read
#54 the broker's post-window notice on CannObserv/broker#85 (CannObserv/broker#95 open, 2026-10-30). For #54 (from #80): ci.yml's Redis fallback, Ubuntu 24.04's apt redis-server, holds only with runs-on pinned to 24.04 (#81's operator decision) 2026-10-30

Out of epic

  • SocratiCode 1.16.0 → 1.16.1: other repos are bumping, but nobody asked Processor to. Boundary decision 1.
  • context-cadence.yml and curating-context: add CannObserv/processor to .skills/cohort — pair it with broker, or unpaired gregoryfoster/skills#343 (Processor's context ledger): agent tooling. Boundary decision 1.
  • co-core 0.39.0 through 0.40.0: nothing Processor imports moved, so no bump. 0.40.0 (2026-10-30) tightens only ContentReplicateCommandEmit and SourceRevisionObservedEmit in co_core.pure.models.changes; Processor uses ContentProcessCommand and the Processing* models from that module [measured, compare v0.39.5…v0.40.0].

Verification debt

What is unverified Why it was skipped How to discharge it Discharged by
A live processor run or processor drift WARNING landing at PRIORITY=4 No forced warnings in production; a transient unit running the same code, user and sandbox proved it (#76) The first real warning after 2026-10-25T15:50:36Z: journalctl -u processor -p warning (open; #77's window may produce one)

Watching

Standing checks

Overlaps

Surface Items
uv.lock, pyproject.toml, src/processor/processors/extract.py the pypdf/pyasn1 advisory issue (draft, awaiting the operator's approval to file)

Measured state

Rewritten from scratch at each check-in, never appended to.

  • processor active, NRestarts=0, live releases/5ef07e29e06a since 2026-10-26T19:13:20Z (boot 19:13:18Z). origin/main 5f2336c differs in no runtime path. Kernel 6.12.113. Measured 2026-10-26T22:15Z.
  • CI green by job on 5ef07e2, d0e73a2 and 5f2336c. Measured 2026-10-26T22:15Z.
  • 0 packages upgradable. /etc/needrestart/conf.d/processor.conf and /etc/apt/preferences.d/tailscale.pref are identical to deploy/. Tailscale AutoUpdate.Apply is false. Measured 2026-10-26T22:15Z.
  • 0 records at -p warning since 2026-10-25T15:50:36Z. Drift ok (202). Measured 2026-10-26T22:15Z.
  • Root disk 79% (15G of 20G); ~/.vscode-server 5.6G. Measured 2026-10-24T18:40Z (not re-read).
  • exe-setup.service enabled, /exe.dev/setup absent, none delivered on 5 boots. Measured 2026-10-26T22:15Z.
  • Main checkout on main, clean, no worktrees; transient processor-patch-77 units gone. Measured 2026-10-26T22:15Z.

Log

Activity

  1. gregoryfoster commented on Oct 27, 2026

    @gregoryfoster
    ContributorAuthor

    #82 check-in pending (implementer, 2026-10-27): #95 merged (875a18c) and deployed. All host steps are done, and co-processor-disk-headroom is enabled and its rehearsal cleared. One thing is left for the coordinator: after the GC's first prune, at 2026-10-28T05:38:06Z, run the checklist on #82 (#82 (comment)). It covers the run result, what was removed, df /, the sensor, and MemoryPeak (for #83). Then record the result and close #82.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions