# 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.