ThothII/docs/superpowers/specs/2026-08-20-psd-survey-remediation-checklist-design.md

PSD Survey Remediation Checklist — Design

Date: 2026-08-20

Status: Approved for documentation

Purpose

Create one versioned operational checklist that lets the owner and Sol discuss the blockers from the PSD server survey one at a time, record decisions without secrets, and resume later from an unambiguous point.

Destination

The operational document will be:

docs/operations/psd-server-survey-remediation-checklist.md

It complements the protected survey evidence. It does not replace the survey report or authorize Project A or Project B.

Structure

The document will contain:

1. a program gate fixed to SURVEY_NO_GO until a fresh bounded survey passes;
2. one explicit Current activity and one Resume from field;
3. a summary table for all ten activities;
4. one section per activity with status, owner, objective, ordered actions, required redacted evidence, discussion notes, decision, blockers, and next step;
5. a final re-survey gate that lists the conditions for SURVEY_GO and explicit owner approval.

Allowed activity states are PENDING, IN_DISCUSSION, BLOCKED, and PASS. Only one activity may be IN_DISCUSSION at a time. Activity 1, controlled rotation of the exposed DWH credential, is the initial current activity.

Activity order

1. Rotate or revoke the exposed DWH credential safely.
2. Identify the accountable owners for every shared component.
3. Resolve the authoritative .it versus .com public origin.
4. Establish the load-balancer topology, ownership, health, TLS, rollback, and allowlist capability.
5. Provide protected read-only Authentik survey access.
6. Provide protected catalog-only PostgreSQL survey access.
7. Prove the legacy ThothII backup and rollback procedure without stopping it during discussion.
8. Provide the server's read-only workspace Git access and current revision evidence.
9. Make Pi and LLM metadata verifiable without disclosing credentials.
10. Retain the report and run only the missing bounded survey checks.

Safety and recording rules

• Never record passwords, tokens, cookies, private keys, connection strings, raw claims, or secret values.
• Record protected paths, owners, modes, timestamps, object names, IDs, checksums, and PASS/FAIL results only.
• Discussion does not authorize mutations. Each operational mutation requires its existing owner, change procedure, rollback, and explicit authorization.
• The legacy stack remains running and unchanged until the survey and backup gates allow otherwise.
• Project A remains forbidden until a fresh report says SURVEY_GO and the owner approves it.
• Project B remains forbidden until Project A has separate automated, human, and owner PASS gates.

Resume contract

At the end of every discussion, update only:

• the activity status;
• sanitized discussion notes and the decision;
• evidence references;
• unresolved blockers;
• Current activity and Resume from.

A later session starts by reading Current activity, then the matching activity section. Completed activities are not reopened unless new evidence invalidates them.

Acceptance

The checklist is acceptable when all ten activities are present in this order, Activity 1 is marked IN_DISCUSSION, every other activity is PENDING, the resume marker points to Activity 1, no secret or realistic secret example is present, and the document explicitly prevents Project A/B from starting early.