Say what the guard's commands look like in a container #25

2026-08-29T16:02:35-07:00

dejima-agent commented

2026-08-29 16:02:35 -07:00

Summary generated by LLM agent

v5 and v6 both finish by telling the operator to run dejima-guard accept on the machine running the guard. That is the host form, and dejima-guard is usually a container.

On a container host there is no dejima-guard on PATH at all, so the note ends in command-not-found on the step whose only job is confirming the upgrade landed. Worse if the operator also installed the host path at some point: then the bare name finds a second deployment, with its own baseline and its own idea of what normal looks like, and it answers as though nothing were wrong.

Both notes name the container form and point at the guard's own README for the rest, rather than growing a copy of another project's interface that would go stale here without anything noticing. A test holds it for any future note that runs the guard.

dejima-guard PR 23 is the other half: the documented run --rm form there did not work at all, because compose keeps the entrypoint and the entrypoint ignored its arguments.

Tested: 188 passing. The new test was run against the notes as they stood and fails on them.

And written down, so the next note gets it right

This repository had no .dejima.md. The container-form rule is the immediate reason for one: an agent writing the next upgrade note will reach for dejima-guard accept, because that is what the guard's own documentation says, and will not think about the deployment shape of another project.

It carries four rules, all of them things this repository learned by shipping the wrong thing and having an operator run it: what an upgrade note has to get right and the three ways its steps have failed, the container form and why it matters more than a missing binary, which of the two version numbers the operator asserts, and that changing what drift collects changes every deployed baseline. Each names the test that holds it, so the next agent extends the test rather than rediscovering the rule.

**Summary generated by LLM agent** v5 and v6 both finish by telling the operator to run `dejima-guard accept` on the machine running the guard. That is the host form, and dejima-guard is usually a container. On a container host there is no `dejima-guard` on `PATH` at all, so the note ends in command-not-found on the step whose only job is confirming the upgrade landed. Worse if the operator also installed the host path at some point: then the bare name finds a second deployment, with its own baseline and its own idea of what normal looks like, and it answers as though nothing were wrong. Both notes name the container form and point at the guard's own README for the rest, rather than growing a copy of another project's interface that would go stale here without anything noticing. A test holds it for any future note that runs the guard. dejima-guard PR 23 is the other half: the documented `run --rm` form there did not work at all, because compose keeps the entrypoint and the entrypoint ignored its arguments. Tested: 188 passing. The new test was run against the notes as they stood and fails on them. ## And written down, so the next note gets it right This repository had no `.dejima.md`. The container-form rule is the immediate reason for one: an agent writing the next upgrade note will reach for `dejima-guard accept`, because that is what the guard's own documentation says, and will not think about the deployment shape of another project. It carries four rules, all of them things this repository learned by shipping the wrong thing and having an operator run it: what an upgrade note has to get right and the three ways its steps have failed, the container form and why it matters more than a missing binary, which of the two version numbers the operator asserts, and that changing what `drift` collects changes every deployed baseline. Each names the test that holds it, so the next agent extends the test rather than rediscovering the rule.

dejima-agent added 1 commit 2026-08-29 16:02:36 -07:00

Say what the guard's commands look like in a container

tests / runner-env (pull_request_target) Successful in 38s

Details

tests / tests (pull_request_target) Successful in 1m15s

Details

358b119741

v5 and v6 both end by telling the operator to run `dejima-guard accept` on the
machine running the guard. That is the host form. dejima-guard is usually a
container, and on that host there is no dejima-guard at all - or worse, one from
a second deployment with its own baseline and its own idea of what normal looks
like. Either way the note ends in command-not-found on the step meant to confirm
the upgrade landed.

Both notes name the container form and point at the guard's own README for the
rest, rather than growing a copy of another project's interface that would go
stale here without anything noticing.

A test holds it for any future note that runs the guard.

dejima-agent added 1 commit 2026-08-29 16:22:44 -07:00

Write down what an upgrade note has to get right

tests / runner-env (pull_request_target) Successful in 40s

Details

tests / tests (pull_request_target) Successful in 1m17s

Details

6e92171be8

This repo had no .dejima.md. The container-form rule is the immediate reason for
one: an agent writing the next note will reach for `dejima-guard accept`,
because that is what the guard's own docs say, and will not think about the
deployment shape of another project.

Four sections, all of them rules this repository learned by shipping the wrong
thing and having an operator run it:

- an upgrade note is a procedure somebody follows verbatim, and the three ways
  the steps here have failed: naming a command the tool does not have, naming
  one the operator's installed copy has not got, and naming one in a form their
  deployment does not have;
- a note that runs dejima-guard needs the container form, with the reason it
  matters more than a missing binary: the bare name can find a second
  deployment with its own baseline and answer as though nothing were wrong;
- which of the two version numbers an operator asserts, and why bootstrap
  records the other;
- that changing what drift collects changes every deployed baseline, so it
  earns a version bump and a re-accept.

Each says which test holds it, so the next agent extends the test rather than
rediscovering the rule.

branderson approved these changes 2026-08-29 16:30:25 -07:00

branderson merged commit 4b9589fb86 into main

2026-08-29 16:30:36 -07:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dejima/dejima-devbox-hardener#25