Flag list — pre-existing Done rows lacking evidence of end-to-end verification¶
Classification: CONFIDENTIAL — Internal Use Only Document:
priorities/flag-list-unverified-done-2026-08-13.md· v1.0 · 2026-08-13 · GPUS-IT Source:priorities/gpus-it-priorities.mdv1.18 · 2026-08-10 (725 lines), read 2026-08-13
What this is, and what it is not¶
This is a list, not an edit. No row in gpus-it-priorities.md was modified to
produce it. Re-adjudication is a later pass.
Every row below is currently marked Done (or sits in the Completed table, or
is struck through as DONE) and predates the status rule now in force:
Done means verified end-to-end via the real production path against live state. Never authored, present, loaded, or validated.
Being on this list does not mean the item is incomplete. It means the document
does not carry evidence that it was verified end-to-end against live state, so its
Done cannot be confirmed from the record alone. Several are probably fine. Two
are contradicted by later evidence and are near-certainly wrong.
Flags are ordered by strength of concern.
Tier A — Done contradicted by later evidence in this repo¶
These are not merely unevidenced. Something else in the repo says the claim was false when written.
A1. Portal backup cron on SKY — Completed 2026-03¶
Claim: gpus-portal-backup.sh nightly 02:30 → GCS.
Contradiction is in the row itself. The Completed table entry carries its own
warning: "⚠ Cron DIED ~2026-04-17 — see the T3 SKY portal-backup item; restore +
backfill needed." The matching T3 item (### SKY portal-backup cron died
(~2026-04-17), line 475) is still open and marked Filed.
Why it flags: this is the exact failure mode the status rule exists to catch —
the cron was verified installed, never verified still running. portals/
snapshots stopped ~4 months ago and the row still reads Completed.
What would settle it: a listing of GCS objects under the portal-backup prefix
showing an object dated within the last 24h, plus systemctl list-timers or
crontab -l output from SKY.
A2. Forms portal LIVE in production — Done 2026-07-23 (summary row line 42 + Completed table)¶
Claim, verbatim: go-live submission 28bd1ebf; routing worker f9a114b on
MAPLE, override OFF; "all 6 ingest addresses verified delivering; HappyFox
tickets opening."
Contradicted by two later documents:
- VLN-011 (
security/finding-2026-08-06-forms-happyfox-never-dispatched.md, confirmed 2026-08-06 read-only against live Cloud SQL + repo) establishes that 0 of 37 submissions had ever received a HappyFox ticket id, 19 sat athappyfox_status='deferred', and no HappyFox client existed anywhere in the repo —HAPPYFOX_URLdeclared atconfig.py:78, never read. "HappyFox tickets opening" was not true on 2026-07-23. governance/forms-field-audit.md(line 191) records as a standing constraint that the ingest addresses are unproven: "Before relying on any of the six unproven addresses, send one test and confirm a ticket number." It further notes a non-ingest-wired mailbox "accepts the mail, opens no ticket, and returns the same250 OK" — i.e. the observation that produced "verified delivering" cannot distinguish success from silent loss.
Why it flags: the go-live row asserts a verified state for the exact mechanism VLN-011 later proved had never run once. The portal being live is not in doubt; the verification claim attached to it is.
What would settle it: per address, one test submission and a confirmed ticket number — the test the field audit already specifies.
Tier B — Done while the row's own stated done-condition is deferred or open¶
B1. Forms 2.5(c) routing worker — Gates 3/4/5 — Completed 2026-07-23¶
Claim: finalize_submission wired; MAPLE-resident Pub/Sub worker via
localhost:25 Postfix; migrations 011 + 012 live. Then, in the same row:
"Residual propagation verification → Portal-propagation workstream."
Why it flags: the v1.15 change log defines "Gate 5 = propagation (NEW,
blocks '2.5(c) done')". The row is marked Done with Gate 5's verification
explicitly handed off — and the receiving item, Portal propagation, is still
Planned in the summary (line 52), including "verify live pages render it." The
condition the doc itself set for "2.5(c) done" has not been met.
What would settle it: the Portal-propagation acceptance — inventory.yaml
reflecting live forms state, validate_portal_presence passing, and live status +
SOC pages fetched and shown rendering forms as LIVE from derived data.
B2. Forms 2.5(d) — subject-template audit-persist + GAP-1 renderer fix + template reconciliation — Completed 2026-07-23¶
Claim: "template reconciliation done."
Contradicted by the Content/data row (line 48): <% = Note => in the Finance
Termination template was "rendering literally in prod" and was only fixed
2026-08-10 — 18 days after reconciliation was declared done. The same row's
live-DB sweep then found a legacy tag on a live template. Separately, "DB↔repo
drift root cause (HIGH)" remains open in that row.
Why it flags: a reconciliation declared done against live templates did not survive contact with live templates. With the drift root cause still unfixed, there is also no acceptance test preventing recurrence.
What would settle it: a query over all 48 live templates showing zero legacy tags, dated, plus a rendered production submission for the previously broken form.
B3. Broken-access-control remediation — Done 2026-07-23 (summary line 43, Completed table, and inline §line 118)¶
Claim: Phase-1 decrypt/list/submit removed; require_role fail-closed;
resolve_user least-privilege; IDOR ownership checks on Phase-2. "No evidence of
exploitation — corroborated independently by two facts: the audit_log is empty
of any decrypt/view events, and the users table is empty."
Why it flags — two distinct issues:
- The evidence supports a different claim than the one being closed. Empty
audit_log+ emptyusersevidences no exploitation occurred. It does not evidence the remediation works. No production-path test is recorded showingrequire_roleactually failing closed or an IDOR attempt actually rejected. - The corroboration is weaker than stated. The two facts are described as
"independent", but an empty
userstable is a plausible common cause of an emptyaudit_log— if no users existed, no decrypt/view events would be logged regardless of authz behaviour. They may be one signal, not two. An emptyuserstable on a portal that had been live also warrants confirming the query hit the production database.
What would settle it: an authenticated negative test against production — a non-owner requesting another user's submission and receiving a denial, with the audit row that denial produces.
B4. Forms Portal Phase 2.5(b) — attachment upload wire-up + cleanup — Completed 2026-05-08¶
Claim: commits e17dacb + 28964c0; migration 002. Row states: "β closed
with verification gap acknowledged (T1.7)."
Why it flags: self-declared. The row records its own unclosed verification gap
and points at T1.7 — which was itself a silent-attachment-drop bug found
during β verification. Closeout doc architecture/forms-phase2.5b-cleanup-closeout.md
acknowledges a verification gap on rev 00043-d9q.
What would settle it: an upload through the production SPA, the object present
in GCS with matching bytes, and the attachment row reaching clean.
Tier C — Done with no verification evidence recorded (no contradiction found)¶
These may well be correct. The record simply does not carry an end-to-end check.
C1. Okta Production cutover — Completed 2026-04-23¶
Claim: production tenant live; group-based assignment; Preview kept as dev
fallback. Open items suggest production app config was never re-checked
against the live console: Okta cleanup — remove localhost redirect URIs is
still Planned, and its done-when (line 322) reads "Production app redirect URI
list contains only https://*.greenpeace.us/* entries" — implying localhost
redirect URIs are present in the production app today. The credential-rotation
item separately flags Okta MFA enforcement as unconfirmed, gating the cutover
notice. Settle with: a live console read of the production app's redirect URI list
and MFA enforcement state.
C2. forms.greenpeace.us DNS + TLS — Completed 2026-04-21¶
Claim: CNAME → ghs.googlehosted.com; managed cert issued. "Issued" is a
control-plane state, not a served-traffic check, and the cutover to that hostname
is still In Progress with legacy running in parallel. Settle with: dig output
plus an HTTPS fetch of the live host showing the cert chain and a 200.
C3. Forms Portal Phase 1 (backend) — Completed 2026-04-20¶
Claim: Cloud SQL PG15, CMEK, IAM auth, AES-256-GCM envelope, RLS 4 roles. No
verification artifact cited for any of the five. Note the Phase-1 endpoints were
later removed by the BAC remediation, and Phase 1.5 (legacy data migration)
and Phase 1.6 (ON CONFLICT refactor) are both still Planned. Settle with: per
control, one live read — instance describe for CMEK/PG15, and \d+ / policy
listing for the four RLS roles.
C4. Meraki P1 inventory — Completed 2026-04¶
Claim: Org 395909, 5 networks, 32 devices. A point-in-time count with no exact
date and no command output; Meraki cleanup — Sedita site + Meraki SSO is still
Planned, so the estate is known to have changed since. Settle with: a dated API
device list.
C5. Okta Preview SSO across 4 portals — Completed 2026-03¶
Claim: OIDC PKCE, shared gpus-okta-auth.js. Preview tenant is by definition
not the real production path, so this cannot satisfy the status rule as written
even if the work is complete. Likely resolution is re-scoping the row rather than
re-testing it.
C6. <% = Note => Finance Termination template — struck through DONE 2026-08-10¶
Evidence given is a template hash (b1a51710e91b8b18 → {{ Note }}) — a change
to stored state, not a rendered production submission. Settle with: one submission
through the live form showing the note rendering correctly.
C7. Live-DB legacy-tag sweep — struck through DONE 2026-08-10¶
Strongest evidence of any row here — an actual live-DB result ("1 of 48 live templates carried a legacy tag... estate now clean"). Flagged only because no query output is reproduced and, with DB↔repo drift root cause still open (HIGH), there is no acceptance test that keeps the estate clean. Settle with: the query text and output, and a recurring check.
Summary¶
| Tier | Count | Meaning |
|---|---|---|
| A — contradicted by later evidence | 2 | Done is near-certainly wrong as written |
| B — own done-condition deferred/open | 4 | Done asserted while its stated gate is unmet |
| C — no verification evidence recorded | 7 | Plausibly complete; unevidenced |
| Total flagged | 13 |
Rows inspected: 3 Done rows in the summary table (lines 42–44), 11 rows in the
Completed table (lines 691–702), the inline DONE section at line 118, and 2
struck-through DONE 2026-08-10 items inside the Content/data summary row.
Overlaps are counted once. Items marked Filed, Planned, Blocked, In
Progress or Deferred are out of scope for this list.
No row in gpus-it-priorities.md was edited.