Migrates TODO.md into pql and removes it. Six tickets: the double- ingestion bug with its full investigation preserved, and an epic covering the four stub endpoints in src/main.py. Markdown TODO lists cannot express blocking, parentage or status, and nothing notices when they go stale. Tickets travel with the repo — .pql/changelog/ is committed and replayed by the git hooks, while the databases are ignored and rebuildable with `pql plan rebuild`. Replaces the feature-branch mandate with the workspace convention: linear history, no merge commits, work on main or a short-lived branch that is fast-forwarded away. tatlock remains the one repo that requires branches. Adds a committed .claude/settings.json. `pql init` writes one containing only allow rules, which is the wrong shape — an allowlist with no floor under it. Every git deny appears in both `git <verb>` and `git * <verb>` form; the second catches `git -C <path>`, and without it the git denies would be decorative. .gitignore gains two entries. `.claude/settings.local.json` was only protected by a global gitignore on this machine, so the protection did not travel with the repo. The .pql rules ignore everything except the changelog, deliberately, since that file is what makes tickets portable. Co-Authored-By: Claude <noreply@anthropic.com>
1.7 KiB
1.7 KiB
Decisions, Questions, Rejected
This directory holds structured planning records that pql parses
into pql.db. Each record is a ### [DQR]-N: Title heading inside
a markdown file. Files live in three per-type subdirectories:
decisions/<domain>.md— confirmed design decisionsquestions/<domain>.md— open questions that may resolve into decisions or rejected proposalsrejected/<domain>.md— rejected proposals (kept for the audit trail)
The parser infers domain from the filename stem and record type from the parent subdirectory.
D-records that propose implementation work link to initiative-type
tickets via decision_ref. Run pql decisions show <id> --with-tickets to inspect implementation status.
Recommended domains
Start with this canonical set; create files as records land in each domain:
- architecture — structural commitments (storage, layering, languages, libraries)
- process — team workflow (commits, branches, releases, reviews)
- design — user-facing surface (UX, UI, public APIs)
- coding-conventions — team-internal code shape (style, lint, file layout)
- testing — quality strategy (coverage, layers, gates)
You might also want, project-permitting:
accessibility— if you ship user-facing softwaresecurity— if you handle user data or network surfaceslicensing— if you release open-source or commercialdocumentation— if user-docs are non-trivialdeployment— if shipping is non-trivialperformance— if you have perf budgets / SLOs
Decisions
- (none)
Open questions
- (none)
Rejected
- (none)