Nicky LeachandPaperclip
c4e80ccdc8
## Thinking Path > - Paperclip uses versioned PostgreSQL migrations to preserve application data. > - Drizzle uses schema snapshots to generate future migrations. > - The database package already prunes snapshots to the five newest files. > - PR #15749 added three snapshots but left eight in the resulting tree. > - This PR removes the three excess files and documents the retention requirements. > - Coding agents and Greptile receive the same scoped rule for future migration changes. ## Linked Issues or Issue Description Refs #15749. Related: #16191 includes overlapping snapshot cleanup with its new migration. This PR isolates the existing excess and the repository rule; it has no dependency on that feature. **What happened?** The migration metadata directory contains snapshots 0331–0338. The existing pruning script retains only the newest five, but the older three were left in master. **Expected behavior** Keep snapshots 0334–0338. Commit snapshot pruning alongside additions and recheck the combined tree after rebases or merges. Preserve all SQL migrations and journal entries. **Steps to reproduce** At master commite3029c632, list `packages/db/src/migrations/meta/*_snapshot.json`. There are eight files. Run `pnpm --filter @paperclipai/db prune:snapshots`; snapshots 0331–0333 are removed. **Paperclip version or commit**e3029c632. Repository maintenance; deployment mode is not applicable. ## What Changed - Remove snapshots 0331–0333 using the existing pruning script. - Add `rules/database-migration-snapshots.mdc` with retention, generation, rebase, preservation, and review requirements. - Register the rule in `.greptile/files.json` with matching scope patterns. ## Verification - Existing `prune:snapshots` script completed successfully via `npm run --prefix packages/db prune:snapshots`. - Existing migration numbering and safety checks passed, run with the available tsx loader. Safety reported only baseline-covered historical findings. - A local assertion check confirmed exactly snapshots 0334–0338 remain, with retained snapshots and journal byte-for-byte equal to the base. SQL migrations are unchanged. - A local assertion check verified that rule globs equal the Greptile scope, all manifest paths exist, representative migration/schema files match, and unrelated server/UI files do not match. - `node scripts/check-maps.mjs` and `git diff --check` passed. - Full application typecheck, test suite, and build were not run for this metadata and review-rule-only change. No runtime code, schema, SQL, or dependencies changed. ## Risks Low risk. The five newest schema snapshots remain unchanged. Database migration history is preserved. The rule supplies agent and review guidance; it does not add a new CI enforcement gate. Recheck retention if another migration merges first. ## Model Used OpenAI GPT-6 via Codex, with reasoning and shell/file tools. The exact runtime model ID and context-window size are not exposed in this session. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge Co-authored-by: Paperclip <noreply@paperclip.ing>
Repository rules
Keep architectural guidance in focused .mdc files here. Each file is Markdown
with YAML frontmatter containing a description and an alwaysApply boolean.
For scoped rules, set alwaysApply: false and provide comma-separated,
repository-relative globs. For repository-wide rules, set alwaysApply: true
and omit globs. Use ** for all descendants of a directory. Include sibling
entry points explicitly when needed.
Root AGENTS.md tells coding agents to read matching rules before editing or
reviewing code. This directory is a repository convention: Cursor does not
automatically load it as .cursor/rules/, and the .mdc extension alone does not
make a tool apply a rule.
Greptile reads matching rule files through .greptile/files.json and receives
loading instructions from .greptile/rules.md. The rule body remains here as
the single source of truth. Repository configuration takes effect when the
files are available on the reviewed branch; local files alone are not visible
to the hosted reviewer.
When adding or changing a rule:
- State the scope, required behavior, examples, exceptions, and review criteria.
- Add its path to
.greptile/files.json. Copy itsglobsinto that entry'sscopearray, one pattern per element. ForalwaysApply: true, omitscope. - Keep the rule's frontmatter and the Greptile scope synchronized. Verify that the scope covers representative files and excludes unrelated directories.
- Keep detailed policy in the rule file instead of copying it into tool settings.
Product behavior is covered by
product-harness-responsibility.mdc: routine
work belongs to the harness, and user-facing detail must support an outcome or a
real decision. This applies to orchestration as well as UI.
See the Greptile file-reference documentation for the manifest format.