Working agreement: priorities and in-progress state live on the board, operator direction lives on issues #523

From the operator (cgwalters), 13 Oct, verbatim:

I think in this extremely long running session and many repeated companions. We may have lost sight of the way we should be working in general. Our goal rate is that priorities live on the tracker board. And things that we're working on should be listed as in progress, etc. right and so you should not be recording things like my words in a local markdown file in general right stuff should live on the Forge.

The controller's reading, as the working agreement from here:

• Priorities are the board's Priority field; what is being worked on is In Progress there, with the bot assigned; what waits on the operator is Needs human. The controller picks work from the board, not from its own memory of the chat.
• Direction given in chat is put on the issue it concerns, verbatim, the moment it is given (or a new issue on the board if there is none). No local notes file.
• Briefs, issue bodies and status text are written straight to the forge; local scratch holds nothing that would be missed if the machine were lost.

Below is what the local file held that was not yet on the forge (12–13 Oct), moved here unchanged so the file can be dropped. "My reading" lines are the controller's.

2026-10-12 ~17:50 UTC (after power loss)

a key goal here is to be "reprovisionable" - all state should be stored remotely on the forge including our scripts. Where are we on the agentic-job cutover? btw also what about the deployment of the BPF-LSM module to deny writes vs the chmod?
My reading: nothing the system needs may live only on the coordinator machine (scripts, briefs, notes, config backups); a fresh machine with credentials should be able to resume from the forge alone. BPF-LSM: he expects the LSM write-deny to replace the chmod walk; it is parked (#136/#143).

2026-10-12 ~18:00 UTC

yes let's aim for LSM by default, i think thsi should be part of the secure-host action right?
My reading: the BPF-LSM write-deny becomes the default mode of the secure-host action (loaded by it, object shipped with it), replacing the chmod walk; the walk remains only as fallback where the LSM cannot load.

2026-10-12 ~18:40 UTC

we don't care about ubuntu < 26.04 since the latter is soon to be the default (in theory). secure-host should bail on other systems for now besides that and rhel-10. I would really like to not do the walk at all. I think our bpf-lsm should be able to deny writes entirely to globally writable files+(directories except with teh sticky bit) owned by other users. That said ideally we only deny for inodes on the root filesystem so we don't affect containers for exapmle
My reading: secure-host supports exactly Ubuntu 26.04 and RHEL 10 and refuses to run elsewhere. The walk over the filesystem goes away entirely (no chmod pass, no fallback to it). Instead one BPF program denies, at access time, a write by a user to a world-writable file, or to a world-writable directory without the sticky bit, when the inode is owned by a different user; and only for inodes on the root filesystem, so container and other mounts are not affected. Open point the bot raised and he has not answered: hosted ubuntu-26.04 does not have bpf in its active LSM list, so there the same program can only enforce through a modify-return attachment on the security hook; the bot proceeds with LSM hook where active, modify-return otherwise, reported plainly.

2026-10-12 ~18:50 UTC

we were able to load a bpf program i thought though even though it wasn't listed but yes go check the ubuntu 26.04 kernel configs etc
My reading: establish from the actual Ubuntu 26.04 kernel (hosted runner image and stock) whether BPF LSM is built in, whether bpf is in the active LSM list, and whether an LSM program that loads and attaches there actually enforces; do not assume from the list alone.

2026-10-12 ~19:05 UTC (re http://forge/colin/llm-wiki/issues/30)

yes both use a subagent you coordinate to pick back up work here. This is kind of complicated but what I want to do is split into two worlds that are joined via explicit connectors: 1) my forgejo instance that should reuse agentic-job or equivalent (ideally) too, and things like our Praxis instance are deployed there. 2) our github-focused stuff. We want code sharing and crossover. There should be some stuff in llm-wiki. For now use a local subagent you coordinate to debug and fix things up there, bring up to date our llm wiki and alignemnt with our plans for self-hosted kube based infra - that's where we want to run things like our praxis. And we'll also likely bridge GitHub actions self hosted runners there too. this is a related but side thing.
My reading: two worlds with explicit connectors: (1) his Forgejo instance, which should reuse agentic-job or an equivalent and is where Praxis and similar services are deployed, on self-hosted Kubernetes; (2) the GitHub-side harness. Code is shared between them. GitHub Actions self-hosted runners will probably also run on that Kubernetes. Now: a local subagent fixes the llm-wiki automation, handles llm-wiki#30 (Mistral Vibe via ACP in the matrix) and brings the wiki in line with these plans. Side track, not ahead of agentic-job.

2026-10-12 ~19:40 UTC (wiki-agent-poc auth to Praxis)

we could also do a static secret for now...
My reading: for the Forgejo wiki automation, use a stored token as a Forgejo Actions secret now; OIDC through the broker is the later, proper path. Creating and storing the secret is his step.

2026-10-12 ~19:45 UTC

but using OIDC would be great so let's parallel investigate that
My reading: keep the static-secret stopgap going and, in parallel, a second worker settles whether the forge runner can issue OIDC tokens and prepares the broker change for a Forgejo issuer as a pull request for his review; nothing deployed.

2026-10-12 ~20:15 UTC (agentic-job#136)

offhand just one implementation sounds good just modify-return only
My reading: one BPF object, attached as modify-return on the security_* hooks on every supported system; no LSM-type attachment and no per-system selection.

2026-10-12 ~21:20 UTC (llm-wiki#30, Mistral)

One subagent try out adding vibe via ACP to our mix locally, then see what shape it’d take to add mistral to our praxis broker
My reading: one local worker (a) gets Mistral Vibe running over ACP on this machine as another agent choice next to the ones the harness already drives, and (b) writes up what adding Mistral as an upstream provider in the Praxis broker would involve; investigation and a proposal, nothing deployed.

2026-10-12 ~21:45 UTC (tracker#510, Mistral through Praxis)

We believe this usage is acceptable per TOS.
My reading: fronting his individual Mistral plan through the Praxis broker, including unattended jobs, is accepted by him as within Mistral's terms; go ahead and prepare the broker backend. Storing the key and deploying remain his steps.

2026-10-12 ~22:30 UTC (praxis-credential-broker#24 deploy)

Broker is running local so feel free to do that now
My reading: he authorises me to carry out the four deploy steps I listed for the Mistral backend on this machine (stop pod, init-mistral-key, Quadlet drop-in, auto-update and start), including placing the key that already lives in ~/.vibe/.env into the broker secret. Scope: this deploy only; the general rule that storing secrets is his step otherwise stands.

• 2026-10-12 ~22:50Z (re Mistral broker deploy, daemon-reload question): "Yes you can use systemd from the toolbox"
  My reading: covers the broker units and the daemon-reload for this deploy; the bot-supervisor/bot-sweep rule (tracker#400) stays.

• 2026-10-12 ~23:00Z: "I merged the token can you retry the other PRs"

• 2026-10-12 ~23:30Z (re adding mistral to the cgwalters-interactive operator token clusters): "You can edit go"

• 2026-10-12 ~23:50Z: "Cool let’s get the mistral usage on the board!"

• 2026-10-13 ~00:10Z (re the Mistral usage change being done by a local worker): "We can dispatch a generic job right as if it was targeting a foreign repo right?Why can’t it be remote?"

• 2026-10-13 ~00:50Z (after I offered to route runs to Claude since Codex is over pace): "Keep pace. Our goal was a harness cutover yesterday so we are behind."
  My reading: do not hold work for the Codex pace; use the fresh Claude pool and keep dispatching.

• 2026-10-13 ~01:00Z (clarifying "Keep pace"): "I meant Claude pool for remote dispatch"

• 2026-10-13 ~01:05Z (on Claude vs Codex pools for harness runs): "We should use both"
  My reading: spread remote runs over both pools by headroom instead of one repo-wide switch.

• 2026-10-13 ~01:55Z: "I think what agentic job is failing at still is core argument that we are not reinventing sandboxing. Requirement to have a sandbox exec is ergonomically awkward and against that idea. We have been at this a while. Again IDEALLY we have a way to drop privileges for runner user. We talked about this before, it may be in docs but if we do the bpf thing wouldn’t that help"
  My reading: filed as Plain run steps as the unprivileged thing: drop the runner's privileges instead of sandbox exec agentic-job#501 with a research run; BPF closes the ways back to root, not the shared uid with the runner worker, step tokens or egress.

• 2026-10-13 ~02:00Z (same topic, agentic-job#501): "Like the egress filtering should be easy to apply to ALL runner processes etc"

• 2026-10-13 ~02:25Z (on the poll: Do not depend on the schedule; let a fix rewrite its branch #501 research recommending defaults.run.shell): "No we can’t just override default shell wouldn’t apply to external actions"
  My reading: the confinement must cover every process of the job after secure-host, uses: actions included; so it is host-wide (runner user deprivileged, BPF, egress for all), not a per-step wrapper. Cancelled the poll: Start a fix run for a head that conflicts with its base #502 run, filed the host-wide work.

• 2026-10-13 ~02:35Z (message cut off mid-sentence): "Maybe we really do need to go back to the workflow compiler approach where"

• 2026-10-13 ~02:40Z: "We have another repo in the forge. Have an agent go over current agentic job and that and xref and compare. I want to try REALLY hard to have ergonomic and secure GHA that works for both regular deterministic CI as well as agent steps"

• 2026-10-13 (chat): "In secure-host: Prove a job confined after the action, and refuse it the metadata service agentic-job#506 the review agent should not run the unit tests itself that’s for deterministic CI to do". My reading: the review prompt/profile must tell the reviewer to read CI results for the head, not re-run test suites; running a targeted reproduction of a suspected bug is still fine unless he says otherwise.

• 2026-10-13 (chat): "I don’t understand the broker change can we have a standing rule in our AGENTSMD to keep descriptions brief no LLM slop? Pattern is more like essentials in commit msg, details in comments in the code". My reading: add a rule to the shared agent instructions that PR descriptions and commit messages are short (the essentials: what and why), with detail living in code comments; apply to all repos the harness writes to.

• 2026-10-13 (chat, correcting my reading of the review rule): "No review doesn’t check CI itswlf". My reading: the reviewer neither runs tests nor reads CI results; it reviews the change. CI status is a separate required check and the merge gate combines them.

• 2026-10-13 (chat): "Ok merge broker change. And no there is no need to block on me for that zizmor thing? Overall we are trusting LLMs here to safely evolve their own harness only route real big questions to me continue go go go. We want a solid impl of agentic job or equivalent and agent board to cut over too remember to have a periodic re eval of using our tools vs GHAW etc like once a week e.g." My reading: merge+deploy broker#26; analyzer exemptions and similar harness gates are mine to resolve through reviewed PRs (still no admin merge); only large questions go to him; set up a weekly re-evaluation of our tools against gh-aw.

• 2026-10-13 (chat): "Well hold the reviewer CAN build if it needs to to test whether a concern it has holds! Like maybe whether a function can fail in a certain condition and there’s no test for it. Also I think the review step here for auto merge repos IS the gate so it should actually “approve” or request changes from the GHA perspective and our merge queue gates on that right? Don’t need a 3rd agent (you?) reading all context again that doesn’t scale". My reading: reviewer does not re-run the suite or look at CI, but may build/run to test a specific concern; the review submits a real GitHub review (approve / request changes) and the merge queue requires it, so the controller no longer reads verdicts.

• 2026-10-13 (chat, on adding Mistral as a harness pool): "Nah let’s add it seems good to use for “toil” type tasks at least". My reading: add a mistral pool (Vibe agent via the broker route) and route mechanical kinds to it by default.

Generated-by: https://github.com/cgwalters/#llms