carlos / platform Public

Clone
git clone https://amadan.net/carlos/platform

Plain git — no account needed to clone.

Download

Download this file

| Earlier finding | Disposition | |---|---| | R1.1 — Manual purge omits settlement | Fixed: Task 7 settles before purge prerequisites and teardown. | | R1.2 — Destructive handlers retain pre-lock decisions | Fixed: existence and protection are rechecked under the lock. | | R1.3 — ErrNotTrashed tests bypass recovery | Fixed: the hook removes the marker between reads and asserts recovery runs. | | R1.4 — Static-instance test accepts unrelated failures | Fixed: requires 201 and verifies the stored record. | | R1.5 — Empty --ttl selects ordinary deployment | Fixed: explicit flag presence is checked and tested. | | R2.1 — Required implementation file omitted from commit | Fixed: Task 5 stages internal/console/svcprincipal.go. | | R2.2 — Settlement breaks trash retries | Fixed: an existing marker permits the ordinary idempotent success path. | | R2.3 — Refusal wording breaks existing assertions | Fixed: API trash and purge reuse their existing refusal wording. |

Reviewed c3bb6fba. Static review only; no files changed or tests run.

  1. P1 — Task 10, Step 3: the browser delete confirmation still promises 30 days. Task 10 changes the success flash but omits the confirmation template from its file list. That template still renders {{trashCooloffDays}} at app_settings.html:492, whose helper always returns 30 at internal/console/server.go:73. A user deleting a temporary app therefore confirms against a promised 30-day restore window, although purge occurs after three days. Spec §5 explicitly includes this confirmation in the consistent-deadline requirement. Fix: make the confirmation’s restore window lifecycle-aware, include its copy in Task 0, and test that temporary and permanent apps display three and 30 days respectively before deletion.
  1. P2 — Task 9, Step 1: the trashed-app refusal test fails before checking the status. At plan:4418, TestTTLAndKeepRefuseWhatTheyCannotChange uses postJSON for requests expected to receive the live-app gate’s plain-text 404. That helper calls doJSON, which unconditionally decodes a nonempty body and calls t.Fatalf on decode failure at authcli_test.go:62. Correct handler behavior thus fails Task 9’s required test run. Fix: use postRaw or rawReq for both expected-404 requests; assert the canonical 404 response and unchanged lifecycle row.

Verdict: revise.

---

FIRST PROMPT: Review the temporary-sites plan at c3bb6fba, round 3, dispositioning earlier findings first.

WHAT: Check implementation-plan fidelity, correctness and tests.

STATUS: Review complete: two new findings; earlier findings addressed.

NEEDED: Nothing.

RECOMMENDED: Revise Task 10’s confirmation display and Task 9’s refusal test.

SESSION: Safe to close. No processes started or files changed; existing untracked files remain.