Files

T

jpmschweitzerandClaude f9f10b322f chore: adopt the workspace agent-config baseline

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>

2026-08-09 03:15:20 +02:00

1.7 KiB

Raw Blame History

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

Decisions

(none)

Open questions

(none)

Rejected

(none)

1.7 KiB Raw Blame History