Audit and reduce post-release repository maintenance burden

[shiny-code-bot]

Objective

Run a bounded post-release audit that reduces Context Panel's maintenance burden without reopening product architecture or weakening the release/runtime safety system that carried 1.0.60 to sale.

The audit should identify tests, fixtures, scripts, workflow assertions, docs, and tracked repository surfaces that create churn without protecting user-visible behavior or an intentional operational contract. Findings must be evidence-classified before removal.

Finish Line

Context Panel retains high-value behavioral and release-safety coverage while redundant, brittle, vestigial, and implementation-coupled maintenance surfaces are removed or explicitly justified.

Current Status

State: Paused in Project Focus Later after deep cleanup on August 13, 2026.
The execution baseline #581, script/CI audit #579, and Swift audit #578 are
complete. Tracked repository-surface cleanup remains available as the separate
parked issue #580 and was not started in this cleanup-only session.

Local-only work was preserved in one external recovery bundle, then stale
branches, stash state, untracked mockups, and the superseded dirty worktree were
removed. The repository is being restored to one clean canonical main
checkout with no open pull requests.

Next action: none for this workstream until #580 is explicitly selected. Do not
resume broad auditing merely because the repository is clean.

Scope

Included:

• Test value, duplication, brittleness, flake risk, runtime cost, and diagnostic quality.
• Behavioral tests versus implementation-shape, source-text, formatting, exact-count, and incidental-value assertions.
• Intentional release, signing, entitlement, privacy, schema, and runtime contracts that must remain explicit.
• Dead or superseded tracked fixtures, scripts, generated scaffolding, documentation, and validation helpers.
• Clear ownership of fast unit gates, integration gates, visual evidence, canonical runtime checks, and release-only checks.
• Measured before/after test counts, runtime, CI behavior, and removed maintenance surface.

Excluded:

• New product features or provider integrations.
• Reopening the completed 1.0.60 release evidence.
• Coverage-percentage targets or deletion quotas.
• Weakening signed-runtime, App Store, CloudKit, privacy, credential, or cross-platform validation contracts.
• Cleanup of untracked local user files without explicit review.

Acceptance Criteria

• Baseline and complete execution mapping Baseline complete test execution before cleanup #581 closes before any deletion or consolidation work begins.
• Every test file is assigned to at least one intentional executable gate; no test exists only in documentation or metadata.
• Every candidate is classified as valuable, replace, consolidate, remove, or accepted maintenance cost.
• Exact pins are distinguished between incidental implementation values and intentional external contracts.
• Every proposed removal or relaxation includes a behavioral counterexample, mutation-style proof, or historical regression evidence showing what the test protects and whether remaining coverage catches the defect.
• Duplicate and tautological tests are removed or consolidated without losing regression coverage.
• Timing-sensitive tests use deterministic coordination where practical.
• Source-text, workflow-text, and docs-phrase tests are replaced with structured or behavioral checks when the text itself is not the contract.
• Visual checks are separated into semantic unit coverage, render smoke checks, and explicit visual-review evidence.
• Dead tracked fixtures, scripts, docs, and generated scaffolding are removed only with reference and history evidence.
• Test runtime and failure diagnostics are measured before and after cleanup using runner-specific baselines.
• Each landing slice is limited to one test file or one coherent candidate class and remains independently revertible.
• scripts/commit-gate.sh, required CI, CodeQL, and applicable inspection gates pass after each landing slice.
• The audit stops when every current file is classified and the evidence-backed candidate backlog is disposed, or when two consecutive review slices produce no high-confidence improvement; remaining concerns become accepted residuals rather than an endless cleanup program.

Relationships

• Follows the completed product audit and maintenance verdict Audit Context Panel for maintenance-ready confidence #425 and Synthesize audit findings and maintenance verdict #433.
• Independent from blocked post-release product plans Consume Work Pulse and deliver tvOS milestone notices #377 and Prototype Tiny Bot PiP as an optional dogfood experiment #378.
• Does not depend on cbusillo/codex-lab#298; this is productive maintenance work while that contract remains parked.
• related: Audit Context Panel for maintenance-ready confidence #425 - Audit Context Panel for maintenance-ready confidence #425
• related: Synthesize audit findings and maintenance verdict #433 - Synthesize audit findings and maintenance verdict #433

Decisions

• Complete test execution mapping and baseline evidence precede judgment about test value.
• Prefer fewer tests with stronger behavioral meaning over maximizing test or line count; raw reduction is not a goal or success metric.
• Do not remove a brittle test until its intended contract is understood and a counterexample, mutation-style check, or historical regression demonstrates replacement safety.
• Keep exact signed identifiers, entitlements, schema fields, safety ordering, cryptographic outputs, and other true external contracts explicit.
• Use runner-specific timing evidence and do not compare unlike self-hosted and GitHub-hosted environments.
• Land at most one test file or one coherent candidate class per PR; keep deletion and replacement changes independently revertible.
• Treat broad speculative findings as audit evidence, not automatic refactor authorization.
• Stop when the classified backlog is disposed or repeated review yields no high-confidence improvement; record accepted cost instead of extending scope.

Validation

• Test inventory and classification ledger.
• Before/after test runtime and failure output comparison.
• Targeted tests for each changed surface.
• scripts/commit-gate.sh.
• GitHub CI and CodeQL.
• JetBrains inspection for changed code.
• Canonical installed runtime only when app/widget/runtime behavior changes.

Open Questions

• Which test categories dominate wall-clock time and historical false-red failures?
• Which source-text checks encode a real policy that needs a structured replacement?
• Which visual checks belong in automated smoke coverage versus explicit gallery/runtime evidence?
• How much tracked release scaffolding remains useful after the successful 1.0.60 train?