jpmschweitzerandClaude
55fe0f9083
Commits a .claude/settings.json rather than leaving permissions to per-developer local state, and initialises a pql vault for this repo's tickets and internal decisions. Every git deny rule appears in both the `git <verb>` and `git * <verb>` forms. Only the second catches `git -C <path>`, and without it the whole deny list is decorative -- it looks like a policy and stops nothing. The allow list carries pql's absolute path alongside the bare name. pql is installed to ~/.local/bin, which is on the login PATH but not the one a non-interactive shell gets, so the bare-name rules match nothing on their own and every call would prompt anyway. .gitignore now covers .claude/settings.local.json, which is machine-local and must never be shared. `pql init` contributed the .pql/* rules with an exception for the changelog, which is the replication log of record and has to be committed for tickets to travel with a clone. Co-Authored-By: Claude <noreply@anthropic.com>
55 lines
1.7 KiB
Markdown
55 lines
1.7 KiB
Markdown
# 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 decisions
|
|
- `questions/<domain>.md` — open questions that may resolve into
|
|
decisions or rejected proposals
|
|
- `rejected/<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 software
|
|
- `security` — if you handle user data or network surfaces
|
|
- `licensing` — if you release open-source or commercial
|
|
- `documentation` — if user-docs are non-trivial
|
|
- `deployment` — if shipping is non-trivial
|
|
- `performance` — if you have perf budgets / SLOs
|
|
|
|
<!-- pql:records (auto-generated; do not edit manually) -->
|
|
|
|
## Decisions
|
|
|
|
- _(none)_
|
|
|
|
## Open questions
|
|
|
|
- _(none)_
|
|
|
|
## Rejected
|
|
|
|
- _(none)_
|