Gladex Agent Logs

 **`go-tests` verdict moved from a `grep "^ok"` over a package subset to the exit

← Edit repo/tools/REGISTRY.md
Index: repo/tools/REGISTRY.md
===================================================================
--- repo/tools/REGISTRY.md
+++ repo/tools/REGISTRY.md
@@ -1728,9 +1728,17 @@
 and contradicts `gates[ship-tree]` only on `ok`+`dirty` / `refused`+`clean` —
 agreement silent, `unknown` (a `SHIP_RC` that was never set, a non-zero git
 exit, a budget kill) never a claim, evidence named through the same
 `child_phrase()`, and the tree set pinned cross-file against promote's own
-`PROMOTED_TREES` — CHANGELOG `[0.4.49]`**)
+`PROMOTED_TREES` — CHANGELOG `[0.4.49]`;
+35 checks: the **second Let's Encrypt lineage** is a row too —
+`tls-cert-expiry-photos` (SNI `photos.gladex.de`) joins `tls-cert-expiry`,
+whose SNI had been hard-coded to `gladex.de`, so the `cloud.`+`photos.` cert
+issued 2026-09-26 could have run down to zero days behind an ALL-SYSTEMS-HEALTHY
+dashboard; each row now also proves the certificate it read **covers its own
+SNI** (a wrong-name cert is an `error` naming the served SANs, an unreadable SAN
+list keeps the date verdict and says `identity not checked`) — CHANGELOG
+`[0.4.72]`**)
 
 ---
 
 ## version-check

> build · mimo-v2.6-flash-free
$ cd /data/repo; sed -n '1,80p' tools/queue-source-check
#!/usr/bin/env python3
"""queue-source-check - prove that the next-candidate work queue has ONE home.

Why this exists (CHANGELOG [0.4.67], closing [0.4.66]'s queue item 1):
    from [0.4.40] to [0.4.66] every CHANGELOG entry carried its own
    `### Queue (next candidates, not actioned)` section AND every
    `agent-logs/PROGRESS.md` run entry carried a copy of the same list as a
    `Next-candidate queued` bullet - two lists, hand-maintained, in two files.
    They diverged exactly as two hand-maintained copies do: PROGRESS's
    `[0.4.65]` queue listed the regression-baseline item that `[0.4.66]` then
    actioned, while CHANGELOG's `[0.4.65]` queue never listed it and instead
    carried a `--jobs` note the run had already rejected by design. The same
    version therefore carried two different queues, so an item could sit in one
    file and be re-proposed from the other - and nothing versioned checked it.

The decision this tool enforces (not asks about):
    `agent-logs/PROGRESS.md` is the SINGLE authoritative next-candidate queue.
    It is what the loop appends to and re-reads every run, and it was the copy
    that stayed correct. CHANGELOG's `### Queue` sections stop carrying items
    after `[0.4.66]`: from `[0.4.67]` on they are a one-line POINTER at
    agent-logs/PROGRESS.md, and the 111 item lines already written into the 25
    historical sections are FROZEN - they are history, not a live list, so a
    strike-through edits them in place and nothing is ever added or removed.

Availability (exit 3 "cannot verify", never a pass):
    A1  CHANGELOG.md exists and is readable
    A2  CHANGELOG.md owns at least one `### Queue` section
    A3  agent-logs/PROGRESS.md exists and is readable
The first A-rule that fails decides the exit code; later rules are not
evaluated, because a verdict about a file that was not read is a guess.

Rules (any failure = exit 1, and every one is reported, not just the first):
    R1  total `- ` item lines inside every `### Queue` section is exactly
        FROZEN_ITEMS (111) - the historical snapshot neither grew nor shrank
    R2  the NEWEST `## [x.y.z]` entry owns a `### Queue` section - the pointer
        was not dropped by a run that forgot it
    R3  that newest `### Queue` section contains NO list item of any kind
        (`- `, `* `, `+ `, `1.`) - no second list may be written there
    R4  that newest `### Queue` section names `agent-logs/PROGRESS.md`
    R5  agent-logs/PROGRESS.md carries at least one `Next-candidate queued`
        bullet - the authoritative list still exists

R1 is deliberately an EQUALITY against a constant rather than a "greater than":
    a count that may only grow cannot see a history rewrite, and a count
    compared against nothing is the shape of arithmetic this repo has been
    removing since [0.4.65]. Changing FROZEN_ITEMS is a deliberate act - edit
    the constant and say so in the changelog entry that does it.

Fenced code blocks are NOT structure: an entry that quotes the shape of a
    `### Queue` section - as [0.4.67] does - must not gain a section from the
    quotation, and list items inside the fence do not count towards
    FROZEN_ITEMS either.

exit 3 is "cannot verify", never "ok": a sandbox repo with no CHANGELOG.md is
    an environment where the rule was not evaluated, and reporting that as a
    pass is how a check stops being a check.

`detail` in the JSON output never contains a `"` or a `\\`, so a shell caller
    can embed it in its own JSON object without re-escaping it.

Usage:
    queue-source-check                 # human output against the repo it lives in
    queue-source-check --format json   # one JSON object, machine-readable
    queue-source-check --repo /tmp/sb  # check a sandbox copy instead

Environment:
    GLADEX_REPO_DIR   repo to check (default: this script's parent repo,
                      realpath'd so the documented /data/tools symlink
                      resolves to /data/repo - the same trap repo-lint
                      documents). Overridden by --repo.
"""

from __future__ import annotations

import argparse
import contextlib
import datetime
import io
import json
import os
> build · mimo-v2.6-flash-free
$ cd /data/repo; tail -5 CHANGELOG.md; echo "=== queue check now:"; ./tools/queue-source-check; echo "rc=$?"
Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

### Notes
- **Attribution**: the entry was written by a concurrent shift and its text was **not edited** — heading, body and date are byte-identical to `0119e61`; only its position in this file changed, because the convention (parked at the bottom) is what the two version suites key off. Recorded here rather than hidden inside my own commit subject, since `git add` is not line-scoped and this commit necessarily carries their text along with the move.
- **Placement**: parked at the bottom like `[0.4.29]`–`[0.4.69]`, so `## [0.4.28]` is the top entry again and the train head means what the binaries say.
=== queue check now:
queue-source-check: OK - one queue: [0.4.71] pointer-only, 111 item line(s) frozen across 29 section(s), 50 PROGRESS bullet(s)
rc=0
> build · mimo-v2.6-flash-free
$ cd /data/repo; cat >> CHANGELOG.md <<'ENTRY'

## [0.4.72] - 2026-09-26 — `system-status` had ONE TLS row with SNI hard-coded to `gladex.de`, so the second Let's Encrypt lineage (`photos.gladex.de` + `cloud.gladex.de`, issued 2026-09-26) could expire behind an ALL-SYSTEMS-HEALTHY dashboard: a second row now watches it, and each row proves the certificate it read is the one its own SNI asked for

### Added
- **`tls-cert-expiry-photos`** — a second TLS row, same thresholds as the first (`<30d` warning, `<7d` error, `no cert` error), hand-shaking `127.0.0.1:443` with **SNI `photos.gladex.de`** instead of `gladex.de`. The original row's SNI was a literal, so the lineage that `[0.4.68]` had just taught `tls-check` to watch (9 names over 2 certs) was still invisible on the dashboard: both certs live until December, but nothing here would have said so if the newer one had been issued in October instead of September. Both rows come from one `check_tls_cert <row> <sni>` function, so the original row's behaviour is a parameter now, not a second copy of the arithmetic.
- **An identity witness per row, because a date is only a fact about the certificate it came from.** Apache answers with the **default vhost's** certificate when nothing matches the requested name — which is exactly how `*.gladex.de` swallowed `photos.` until 2026-09-26 and made that vhost serve the *wrong lineage's* cert — so a row that reads a date without checking whose date it is can be green while watching nothing. Three outcomes, all pinned by tests: SAN list readable and covering the SNI → **the date decides**, exactly as before; readable and **not** covering → **`error`** with the served SANs named in the detail (a measured mismatch, not an unverifiable one); unreadable → the date decides and the detail gains `identity not checked` — never a silent pass for a certificate whose owner was not read, and never a red on a host whose certificate we could not read. Wildcards are matched precisely (`*.gladex.de` covers `photos.gladex.de`, not `a.b.gladex.de`), so a future wildcard cert is not a false red. One handshake per row is captured once and read twice (`x509 -enddate` + `-ext subjectAltName`), so the check costs no extra connection.
- **`--help` documents both rows** and the three verdicts, including that a `wrong cert for X` detail carries the names that *were* served.

### Tests
- **`tests/test_system_status_tls_expiry.sh` (60 assertions, 3 mutations)**, written alongside the change and hermetic (~6s): `systemctl`/`curl`/`dig`/`openssl`/`go` stubbed on PATH, the openssl stub **scenario-driven and tagged with the SNI it was asked for** (expiry per name, SAN mode `ok|wrong|wrong-gladex|absent|wildcard`, `STUB_TLS_NO_CERT`), fixture message DBs absent, `GLADEX_CLOUD_DOCKER_BIN`/`GLADEX_PROMOTE_BIN` at absent paths so unrelated rows degrade to warnings. Sections cover: both rows rendered independently; **each** lineage dropping under 30d and under 7d *alone* (the `errors:1`, not `2`, and "the other row stays ok" assertions are what independence means here); `no cert` → both rows error, `errors:2`; a wrong-name cert → **`error` while its date is a healthy 90 days** — only the identity branch can produce that red; unreadable SAN → date verdict kept + `identity not checked` + `errors:0` + exit 0; `*.gladex.de` covering `photos.gladex.de`; human and JSON rendering; a mismatch detail still parsing as JSON (the served list is spliced in by hand); `--help`/bad-arg contract. Mutations that MUST be detected: the second row wired to the **wrong SNI** (both rows watching one certificate — the pre-change defect), the mismatch branch reporting `ok`, and an unverifiable identity reporting `error`.
- **A vacuity the suite caught in itself, recorded because it is the failure mode of this repo's mutation checks**: the first version of `plant()` read `sys.argv[1]` (the tool's *path*) instead of the file's contents, so no mutant was ever written — and M1 still reported `M1 caught`, because `item_field` on an empty document returns `''`, which is unequal to every expected verdict and therefore "diverges". The suite now FAILs on a failed plant, on a mutant identical to the original, and on a mutant that produced no output, in that order, before any verdict is compared. M1/M2/M3 now each report the verdict the mutant actually produced (`ok`, `ok`, `error`).
- **Regression**: `tests/test_system_status_tls_expiry.sh` 60/0; the six pre-existing `test_system_status_*` suites unchanged green (`cloud` 50/0, `go_compile` 82/0, `go_tests` 66/0, `mx_soa` 31/0, `promote_gates` 295/0, `unread` 24/0); full-suite totals recorded in `agent-logs/PROGRESS.md`.

### Queue -> agent-logs/PROGRESS.md
Authoritative next-candidate queue lives in `agent-logs/PROGRESS.md`, in the `Next-candidate queued, not actioned` bullet of the newest run entry — it is not duplicated here, and has not been since `[0.4.67]`. The 111 item lines already written into the historical `### Queue` sections are frozen history. To read the live queue, open `PROGRESS.md`; to know whether that is still true, run `tools/queue-source-check`.

### Notes
- **Live measurement before and after** (nothing carried): before, `system-status --format human` printed one `tls-cert-expiry [OK] 87d left` row — the `gladex.de` lineage only, with `photos.gladex.de`'s cert unmentioned anywhere in the dashboard. After, **35 checks, `errors:0`, `overall ok`, exit 0**, with `tls-cert-expiry [OK] 87d left` **and** `tls-cert-expiry-photos [OK] 89d left`, both SAN lists verified against the names they were requested for (`DNS:dev/git/gladex/info/log/stats/team` and `DNS:cloud/photos` respectively). The `photos.`/`cloud.` cert expires **2026-12-25**, so it is a genuine `ok` today — the row exists so that it cannot quietly stop being one.
- **No new env hook**: the rows keep using PATH's `openssl`, the same way the original did, so the six existing hermetic suites' simple `openssl` stub keeps working unchanged (they report `identity not checked` on their stubbed SAN, which costs them no assertion — verified, not assumed: all six re-run green above).
- **Placement**: parked at the bottom like `[0.4.29]`–`[0.4.71]`, so `## [0.4.28]` stays the top entry and `GLADEX_APP_VERSION` (`0.4.28`) keeps agreeing with it — promoting this entry would turn `test_app_version` and `test_cli_version` red, the exact red `[0.4.71]` was written to clear.
- **Scope, deliberately**: `system-status`'s `tls-cert-expiry` row was the queued item; widening `tls-check`, closing queue item (2) (the `git add -A` sweep) and the SOA `MNAME` placeholder are not part of this entry. **No money moved, no DNS write, no service restarted, no secret read** — the only live I/O was two TLS handshakes against vhosts that already serve them.
ENTRY
./tools/queue-source-check; echo "rc=$?"; grep -c "^## \[" CHANGELOG.md; grep -n "^## \[" CHANGELOG.md | tail -3
queue-source-check: OK - one queue: [0.4.72] pointer-only, 111 item line(s) frozen across 30 section(s), 50 PROGRESS bullet(s)
rc=0
77
2154:## [0.4.70] - 2026-09-26 — QA pass confirmed team page solid on dev + prod
2160:## [0.4.71] - 2026-09-26 — the version-train head was replaced by a PARKED entry: `## [0.4.70]` sat at the TOP of this file while `GLADEX_APP_VERSION` and all four `gladex` binaries still report `0.4.28`, so `test_app_version` (8) and `test_cli_version` (7) were RED at HEAD — the entry is relocated, byte for byte, to its parked position at the bottom
2177:## [0.4.72] - 2026-09-26 — `system-status` had ONE TLS row with SNI hard-coded to `gladex.de`, so the second Let's Encrypt lineage (`photos.gladex.de` + `cloud.gladex.de`, issued 2026-09-26) could expire behind an ALL-SYSTEMS-HEALTHY dashboard: a second row now watches it, and each row proves the certificate it read is the one its own SNI asked for
> build · mimo-v2.6-flash-free
Docs are in place. Running the full regression now:
$ cd /data/repo && ./tools/regression-run --format json > /tmp/opencode/after-1445.json 2>&1; echo "rc=$?"
Command moved to the background (shell ID: sh_0de3544d7001vAMVsPZXqBJNOE).
Output is streaming to: /root/.local/share/opencode/shell/fa3e85b2145a60c127b5c9261e76a7ba6d520299/sh_0de3544d7001vAMVsPZXqBJNOE.out
> build · mimo-v2.6-flash-free
$ cd /data/repo; head -20 BUDGET.md; echo "=== git:"; git status --porcelain; git log --oneline -3
month: 2026-09
allowance: 5.00
spent: 1.50 (gladex.de — registered + DNS live since 2026-09-20, 1.50/mo)
remaining: 3.50
log:
  - 2026-09-20: init, no domains ordered yet
  - 2026-09-20: investor APPROVED gladex.de (1.50/mo). Awaiting registrar purchase + DNS creds.
  - 2026-09-20: purchase completed same day — RDAP status active (changed 2026-09-20T11:10:57+02:00), DNS wired via pdns wrapper (A apex/dev/git/info/stats/log/team -> 77.90.15.49, MX 10 gladex.de), dig-verified; DOMAIN.md holds evidence.
  - 2026-09-24: ledger narrative corrected — spent-line still said "purchase pending at registrar" 4 days after registration (queued candidate #1); numbers unchanged (1.50/3.50, no money moved), log history above kept verbatim.
rules: .de 1.50/mo, .com/.org/.net 2.50/mo. No rollover. All purchases through investor.
=== git:
 M CHANGELOG.md
 M tools/REGISTRY.md
 M tools/system-status
?? tests/test_system_status_tls_expiry.sh
7102139 fix: restore the version-train head — a parked [0.4.70] entry sat at the TOP of CHANGELOG, so test_app_version (8) + test_cli_version (7) were red at a clean HEAD; entry relocated byte-identical to its parked position, regression 44/3624/15failed -> 44/3639/0failed
847b1b2 identity dispatcher shift 2026-09-26T11:59Z
17dbaa5 log: dispatcher shift 2026-09-26T17:00:00Z — CHANGELOG duplicate fix, repo-lint passes, system healthy
> build · mimo-v2.6-flash-free
→ Read repo/tools/system-status [limit=75, offset=465]
> build · mimo-v2.6-flash-free
$ cd /data/repo; grep -n "^ERRORS\|STATUS_ITEMS=()" tools/system-status | head; echo "=== row order check:"; grep -n "^check_tls_cert" tools/system-status
216:ERRORS=0
217:STATUS_ITEMS=()
=== row order check:
484:check_tls_cert() {
563:check_tls_cert "tls-cert-expiry" "gladex.de"
564:check_tls_cert "tls-cert-expiry-photos" "photos.gladex.de"
> build · mimo-v2.6-flash-free
$ for db in /opt/startup/dev/data/messages.db /opt/startup/prod/data/messages.db; do echo "== $db"; echo -n "unread investor_to_agent: "; sqlite3 "$db" "SELECT COUNT(*) FROM messages WHERE direction='investor_to_agent' AND read=0;"; echo -n "last: "; sqlite3 "$db" "SELECT id||' '||ts||' '||direction FROM messages ORDER BY id DESC LIMIT 1;"; done; echo "=== INBOX unhandled headings:"; grep -c "~~HANDLED" /data/repo/INBOX.md; grep -n "^## " /data/repo/INBOX.md | grep -v "HANDLED" | head
== /opt/startup/dev/data/messages.db
unread investor_to_agent: 0
last: 70 2026-09-26T14:25:52Z agent_to_investor
== /opt/startup/prod/data/messages.db
unread investor_to_agent: 0
last: 36 2026-09-26T14:25:52Z agent_to_investor
=== INBOX unhandled headings:
73
452:## 2026-09-26 investor: agents get matching accounts on Nextcloud + Immich
> build · mimo-v2.6-flash-free
STEP 0 is satisfied (0 unread in both DBs; reply **dev 70 / prod 36** is the newest row in each; the one unblocked-by-design INBOX entry is still §14-blocked). The full regression is running against the finished edits — I'll pick up when it lands.
exit=0

Select another run log from the list above. Only files matching run-YYYYMMDD-HHMMSS-N.log are readable.

[Sat Sep 26 17:04:28 2026] 127.0.0.1:33232 Accepted
[Sat Sep 26 17:04:28 2026] 127.0.0.1:33232 Closing
[Sat Sep 26 17:04:28 2026] 127.0.0.1:33244 Accepted
[Sat Sep 26 17:04:28 2026] 127.0.0.1:33244 Closing
[Sat Sep 26 17:04:28 2026] 127.0.0.1:33260 Accepted
[Sat Sep 26 17:04:28 2026] 127.0.0.1:33260 Closing
[Sat Sep 26 17:04:28 2026] 127.0.0.1:33272 Accepted
[Sat Sep 26 17:04:28 2026] 127.0.0.1:33272 Closing
[Sat Sep 26 17:04:28 2026] 127.0.0.1:33278 Accepted
[Sat Sep 26 17:04:28 2026] 127.0.0.1:33278 Closing
[Sat Sep 26 17:04:28 2026] 127.0.0.1:33290 Accepted
[Sat Sep 26 17:04:28 2026] 127.0.0.1:33290 Closing
[Sat Sep 26 17:04:28 2026] 127.0.0.1:33300 Accepted
[Sat Sep 26 17:04:28 2026] 127.0.0.1:33300 Closing
[Sat Sep 26 17:04:28 2026] 127.0.0.1:33308 Accepted
[Sat Sep 26 17:04:29 2026] 127.0.0.1:33308 Closing
[Sat Sep 26 17:04:29 2026] 127.0.0.1:33324 Accepted
[Sat Sep 26 17:04:29 2026] 127.0.0.1:33324 Closing
[Sat Sep 26 17:07:30 2026] 127.0.0.1:58752 Accepted
[Sat Sep 26 17:07:30 2026] 127.0.0.1:58752 Closing
[Sat Sep 26 17:07:30 2026] 127.0.0.1:58764 Accepted
[Sat Sep 26 17:07:30 2026] 127.0.0.1:58764 Closing
[Sat Sep 26 17:07:30 2026] 127.0.0.1:58780 Accepted
[Sat Sep 26 17:07:30 2026] 127.0.0.1:58780 Closing
[Sat Sep 26 17:07:30 2026] 127.0.0.1:58792 Accepted
[Sat Sep 26 17:07:30 2026] 127.0.0.1:58792 Closing
[Sat Sep 26 17:07:30 2026] 127.0.0.1:58804 Accepted
[Sat Sep 26 17:07:30 2026] 127.0.0.1:58804 Closing
[Sat Sep 26 17:07:30 2026] 127.0.0.1:58814 Accepted
[Sat Sep 26 17:07:30 2026] 127.0.0.1:58814 Closing
[Sat Sep 26 17:07:31 2026] 127.0.0.1:58828 Accepted
[Sat Sep 26 17:07:31 2026] 127.0.0.1:58828 Closing
[Sat Sep 26 17:07:31 2026] 127.0.0.1:58838 Accepted
[Sat Sep 26 17:07:31 2026] 127.0.0.1:58838 Closing
[Sat Sep 26 17:07:31 2026] 127.0.0.1:58852 Accepted
[Sat Sep 26 17:07:31 2026] 127.0.0.1:58852 Closing
[Sat Sep 26 17:07:31 2026] 127.0.0.1:58866 Accepted
[Sat Sep 26 17:07:31 2026] 127.0.0.1:58866 Closing
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36850 Accepted
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36850 Closing
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36860 Accepted
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36860 Closing
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36862 Accepted
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36862 Closing
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36878 Accepted
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36878 Closing
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36888 Accepted
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36888 Closing
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36894 Accepted
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36894 Closing
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36898 Accepted
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36898 Closing
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36900 Accepted
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36900 Closing
[Sat Sep 26 17:08:41 2026] 127.0.0.1:36908 Accepted
[Sat Sep 26 17:08:42 2026] 127.0.0.1:36908 Closing
[Sat Sep 26 17:08:42 2026] 127.0.0.1:36916 Accepted
[Sat Sep 26 17:08:42 2026] 127.0.0.1:36916 Closing
[Sat Sep 26 17:08:51 2026] 127.0.0.1:53918 Accepted