Rebuild, or fix it?

Create a privacy-safe structural snapshot of this repository for its owner to review before deciding whether to share it with an outside technical reviewer.

## Operating constraints

- Work entirely on this machine. Make no network requests and do not install dependencies.
- Read the repository, its local Git metadata, and existing tool output only. Do not modify repository state or any existing file other than `system-snapshot.md`.
- Write exactly one file in the repository root: `system-snapshot.md`. If it already exists, replace it. Do not create temporary files.
- Use the fixed output template below without adding sections, prose, examples, recommendations, file paths, or appendices.
- Fill a field only when the repository provides direct evidence. Otherwise write `unknown`. Do not guess.
- Report counts, categories, booleans, date ranges, and product names only. Never include code, excerpts, matches, filenames, paths, schema or table names, endpoint names, environment-variable names, people, customers, business rules, proprietary algorithms, or project-specific identifiers.
- Never print or copy a secret to prove it exists. Credential checks may return counts only, including when checking Git history.
- Treat ignored files, generated output, vendored dependencies, build artifacts, and dependency directories as out of scope unless they are committed source.
- Treat a capability as detected only when executable source, configuration, tests, or machine-readable fixtures implement it. Mentions in prose, documentation, content, comments, examples, or this prompt are not evidence.
- Do not turn absence of evidence into a claim that an architectural property is absent. Use `unknown` unless the repository directly establishes the negative. For an evaluation harness, require executable evaluation logic; for a golden dataset, require a committed machine-readable fixture referenced by that logic.
- Count a source file only when it is tracked, hand-written executable code in a language reported under Scale. Exclude tests, fixtures, migrations, configuration, documentation, content, static assets, generated output, lockfiles, and vendored dependencies. A test file is a tracked executable test, not a filename that merely contains the word `test`.
- For the commit-history range, use the earliest and latest dates across all commits reachable in the local current branch. If the local history is shallow or incomplete, write `unknown` instead of reporting a partial range.
- Count a generated-code marker only when a tracked source file has a standard generated-file header such as `generated` or `do not edit`. Count files, not matching lines. Count editor-agent configuration sets at the product-configuration level, not individual files.
- A credential-pattern match requires a high-confidence secret-bearing construct: a private-key header, a credential-bearing URI, or a non-placeholder literal assigned to a key/token/secret/password field. Environment-variable references, field names without values, hashes, public identifiers, documentation, examples, fixtures, and placeholder values do not count. Count each matching file once. If the working tree or reachable Git history cannot be checked exhaustively without revealing matches, report `unknown` for that count.

## Required output template

```markdown
# System Snapshot

Generated locally. Contains no code, credentials, filenames, file paths, schema names, endpoint names, business logic, customer information, people, or proprietary algorithms. [N] items were withheld by the redaction pass.

## Scale

- Languages: [names and approximate line counts]
- Committed source files: [N]
- Largest source file: [approximate lines only]
- Test files / source files: [N / N]
- Commits: [N]
- Contributors: [N]

## Stack

- Frameworks and runtimes: [product names and detected versions, or unknown]
- Database: [product name only, or not detected]
- Hosting: [product name only, or not detected]
- Authentication: [product name only, or not detected]
- Payments: [product name only, or not detected]
- AI providers: [product names only, or not detected]
- Background jobs: [product name or mechanism category only, or not detected]

## How it was built

- Coding-agent artifacts: [detected / not detected]
- Generated-code markers: [N]
- Editor-agent configuration sets: [N]
- Commit-history date range: [YYYY-MM-DD to YYYY-MM-DD, or unknown]

## Structural observations

- Source files over 1,000 lines: [N]
- Database tables: [N or unknown]
- Tables with row-level security: [N or unknown]
- Environment variables referenced: [N]
- Files matching credential patterns: [working tree N; Git history N or unknown]
- Migrations: [N]; without a detected down path: [N or unknown]
- Test-to-source-file ratio: [ratio]
- CI configured: [yes / no]; test failures block CI: [yes / no / unknown]
- Staging environment detected: [yes / no / unknown]
- Error tracking or structured logging detected: [yes / no / unknown]
- Multi-tenancy detected: [yes / no / unknown]; isolation category: [database policy / application filter / separate database / absent / unknown]
- Evaluation harness detected: [yes / no / unknown]; golden dataset detected: [yes / no / unknown]

## State of the product

- Live users: [founder to complete]
- Payments live: [founder to complete]
- Running in production: [founder to complete]

## What this report cannot tell you

Source code alone cannot establish whether observed behaviour is intended, whether the tests assert the right behaviour rather than the current one, whether undocumented production state differs from the repository, whether the operating team can recover the system under pressure, or whether a buyer, auditor, or regulator will accept its controls. It cannot predict the system's real production limit, price the risk of its architectural decisions, or decide whether remediation is safer and cheaper than a rebuild. Those answers require a human read of the code, operating context, and commercial constraints.
```

## Final redaction pass

Before writing `system-snapshot.md`, inspect every value in the completed template. Replace any disallowed detail with its count, category, `withheld`, or `unknown`. Count every replacement and put that number in the integrity line. Verify that the final file contains only the headings and fields in the template, then write that one file.