Pin the workflow to main, and put the wordmark on the README #12

2026-08-08T20:29:20-07:00

dejima-agent commented

2026-08-08 20:29:20 -07:00

Summary generated by LLM agent

Two unrelated changes that both became possible once #10 and #11 landed on main.

Read the workflow only from `main`

The file carried pull_request alongside pull_request_target because a workflow read from the base branch cannot test the change that introduces it. That is done, so the second trigger goes and the header stops describing a transition rather than what the file does: the workflow comes from main, so a branch cannot repoint runs-on: at a runner nothing hardened.

The two runner-env jobs drop their explicit ref: at the same time and for the same reason. They assert on the runner rather than on the change, so their assertions should come from main — which is what a bare checkout gives under pull_request_target, and which means a branch can neither weaken those tests nor delete them. test/ci-runner.bats is on main now, so a bare checkout finds it.

The jobs that do test the change keep naming the head permanently; without a ref they would check out the base branch and pass regardless of the change.

job	checkout
`tests`	head.sha
`compose-schema`	head.sha
`runner-env (confined)`	bare — base branch
`runner-env (privileged)`	bare — base branch

Wordmark on the README

Above a heading that now reads Continuous Integration Hardener — the acronym spelled out, and no second "dejima" after the one the wordmark already carries.

The wordmark is a fixed file rather than anything preference-aware. prefers-color-scheme reports the browser's setting, never the site's, and this is read on a forge that renders dark whichever way the browser is set — so a conditional version shows dark ink on a dark page to a reader whose browser prefers light, and does it silently. Both ink colours are committed so a mirror on a light-themed host changes one filename rather than a filename and an asset.

The marks are trademarks and are not covered by the GPL that covers the code. Rather than restate that here, the README and assets/README.md point at dejima's ATTRIBUTION.md, which is the single statement for the organisation. Those links are absolute: a fork resolving a relative one would find its own copy of the terms instead of the canonical one.

Also: the address guard skips binary files now. It passed on these images by luck, and one whose bytes happened to look like an address would have failed a check on a file nobody can read or fix.

Merge order

This depends on dejima/dejima carrying ATTRIBUTION.md first — both links here point at it, and until it exists they are links to a 404.

Tested

bats test/ — 87 ok, 0 failed. The header was rendered through the forge's markdown API to confirm it resolves to the cream wordmark; every intra-repository link and anchor resolves.

**Summary generated by LLM agent** Two unrelated changes that both became possible once #10 and #11 landed on `main`. ## Read the workflow only from `main` The file carried `pull_request` alongside `pull_request_target` because a workflow read from the base branch cannot test the change that introduces it. That is done, so the second trigger goes and the header stops describing a transition rather than what the file does: the workflow comes from `main`, so a branch cannot repoint `runs-on:` at a runner nothing hardened. The two `runner-env` jobs drop their explicit `ref:` at the same time and for the same reason. They assert on the *runner* rather than on the change, so their assertions should come from `main` — which is what a bare checkout gives under `pull_request_target`, and which means a branch can neither weaken those tests nor delete them. `test/ci-runner.bats` is on `main` now, so a bare checkout finds it. The jobs that do test the change keep naming the head permanently; without a ref they would check out the base branch and pass regardless of the change. | job | checkout | | --- | --- | | `tests` | head.sha | | `compose-schema` | head.sha | | `runner-env (confined)` | bare — base branch | | `runner-env (privileged)` | bare — base branch | ## Wordmark on the README Above a heading that now reads **Continuous Integration Hardener** — the acronym spelled out, and no second "dejima" after the one the wordmark already carries. **The wordmark is a fixed file rather than anything preference-aware.** `prefers-color-scheme` reports the *browser's* setting, never the site's, and this is read on a forge that renders dark whichever way the browser is set — so a conditional version shows dark ink on a dark page to a reader whose browser prefers light, and does it silently. Both ink colours are committed so a mirror on a light-themed host changes one filename rather than a filename and an asset. The marks are trademarks and are not covered by the GPL that covers the code. Rather than restate that here, the README and `assets/README.md` point at **dejima's `ATTRIBUTION.md`**, which is the single statement for the organisation. Those links are absolute: a fork resolving a relative one would find its own copy of the terms instead of the canonical one. Also: the address guard skips binary files now. It passed on these images by luck, and one whose bytes happened to look like an address would have failed a check on a file nobody can read or fix. ## Merge order **This depends on `dejima/dejima` carrying `ATTRIBUTION.md` first** — both links here point at it, and until it exists they are links to a 404. ## Tested `bats test/` — 87 ok, 0 failed. The header was rendered through the forge's markdown API to confirm it resolves to the cream wordmark; every intra-repository link and anchor resolves.

dejima-agent referenced this pull request

2026-08-08 22:48:25 -07:00

State plainly that there is no support, and where to send a vulnerability #13

dejima-agent added 1 commit 2026-08-08 23:25:00 -07:00

Put the wordmark on the README, and point at the canonical terms

tests / compose-schema (pull_request_target) Successful in 1m34s

Details

tests / runner-env (privileged) (pull_request_target) Successful in 1m23s

Details

tests / runner-env (confined) (pull_request_target) Successful in 1m25s

Details

tests / tests (pull_request_target) Successful in 1m50s

Details

9c49451529

The suffix names the mode a file is for, not the colour of its ink, so `-darkmode` is the pale wordmark that belongs on a dark page. Naming by ink reads backwards at the moment someone is picking a file in a hurry, and it collides with the logo variants, which are already named by mode.

The README points at one file unconditionally rather than switching on `prefers-color-scheme`, which reports the browser's setting and never the site's. A forge that renders dark whichever way the browser is set would then show dark ink on a dark page, silently, to a reader whose browser prefers light. Both files ship, so a mirror on a light-themed host changes one line where someone can see whether it worked.

The artwork is not covered by the GPL. Both the README and assets/README.md point at dejima's ATTRIBUTION.md for who holds the marks and what may be done with them, by absolute link, so a fork resolving it does not find its own divergent copy of the terms.

dejima-agent force-pushed branding-and-triggers from 704b7527a7 to 9c49451529

2026-08-08 23:25:00 -07:00

Compare

branderson approved these changes 2026-08-09 03:13:50 -07:00

branderson merged commit 2b4c18f59e into main

2026-08-09 03:13:57 -07:00

branderson referenced this issue from a commit

2026-08-09 03:13:58 -07:00

Merge pull request 'Pin the workflow to main, and put the wordmark on the README' (#12) from branding-and-triggers into main

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dejima/dejima-ci-hardener#12

Pin the workflow to main, and put the wordmark on the README #12

Read the workflow only from main

Wordmark on the README

Merge order

Tested

Read the workflow only from `main`