mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-06-21 07:11:13 +00:00
6044a33197
Bundled hygiene commit before cycle-3 /implement (AZ-776, AZ-777). Mixes two concerns by user choice (autodev option B): - Cycle-3 autodev artifacts not yet committed by Step 9 (new-task): task specs for AZ-776 / AZ-777 under _docs/02_tasks/todo/ and the updated _docs/02_tasks/_dependencies_table.md. - Accumulated skill / rule tooling maintenance under .cursor/ (skills: autodev, code-review, decompose, deploy, implement, new-task, plan, refactor, retrospective, test-spec; rules: coderule, cursor-meta, meta-rule, testing; new release skill scaffolding). - Autodev bootstrap state: _docs/_autodev_state.md (step 10 in_progress) and _docs/_process_leftovers/2026-05-11_d_cross_cve_1_opencv_pin_deferred.md (replay timestamp refreshed; gtsam 4.2 still numpy<2-only). Co-authored-by: Cursor <cursoragent@cursor.com>
68 lines
3.0 KiB
Markdown
68 lines
3.0 KiB
Markdown
# ADR-{NNN}: {decision-title}
|
||
|
||
- **Status**: {Proposed | Accepted | Deprecated | Superseded}
|
||
- **Date**: {YYYY-MM-DD}
|
||
- **Deciders**: {user / project owner}
|
||
- **Supersedes**: {ADR-NNN | —}
|
||
- **Superseded by**: {ADR-NNN | —}
|
||
|
||
## Context
|
||
|
||
What problem does this decision address? Cite the relevant constraint(s), acceptance criterion / criteria, and risk(s) by ID.
|
||
|
||
- Acceptance criteria addressed: AC-{ID-1}, AC-{ID-2}
|
||
- Restrictions addressed: R-{ID-1}, R-{ID-2}
|
||
- Risks addressed: RISK-{ID-1}
|
||
- Research source (if any): `_docs/01_solution/solution_draftN.md` § {section}
|
||
|
||
A short paragraph (3–6 sentences) explaining why a choice is required now and what makes it non-trivial. Do not pre-announce the decision here — that goes in `Decision`. Focus on the forces at play (load, scale, team familiarity, hardware constraints, regulatory drivers, third-party limits).
|
||
|
||
## Decision
|
||
|
||
One declarative sentence: **"We will …"** Then 1–3 paragraphs of supporting detail explaining how the decision will be implemented at the boundaries between components.
|
||
|
||
Be specific. "We will use Postgres" is too thin; "We will use Postgres 16 with logical replication for read scaling, restricting JSONB columns to top-level metadata only, with all transactional data in normalized tables" is the right resolution.
|
||
|
||
## Alternatives Considered
|
||
|
||
| Alternative | Rejected because |
|
||
|-------------|------------------|
|
||
| {Alt 1 — short label} | {one line: the cost / mismatch / risk that ruled it out, ideally referencing a measurable criterion} |
|
||
| {Alt 2 — short label} | {one line} |
|
||
| {Alt 3 — short label} | {one line} |
|
||
|
||
At least one rejected alternative is mandatory. If only one option was ever considered, this is not an ADR — link to the source restriction or research selection from the parent doc instead.
|
||
|
||
## Consequences
|
||
|
||
### Positive
|
||
|
||
- {What becomes easier / cheaper / faster, with concrete examples where possible}
|
||
- {…}
|
||
|
||
### Negative
|
||
|
||
- {What becomes harder / locked in / costly to undo}
|
||
- {…}
|
||
|
||
Every real decision has both. If the negatives section is hard to fill, the alternatives were probably not weighed seriously — return to the prior step.
|
||
|
||
### Neutral / Open
|
||
|
||
- {What is unchanged but worth flagging for future readers (e.g., "this does not change the auth boundary; auth remains in component 02_user_management as decided in ADR-003")}
|
||
|
||
## Evidence
|
||
|
||
Where this decision is reflected on disk. Use `file:section` links so future readers can jump.
|
||
|
||
- `_docs/02_document/architecture.md` § {section}
|
||
- `_docs/02_document/data_model.md` § {section}
|
||
- `_docs/02_document/components/{##_name}/description.md` § {section}
|
||
- `_docs/02_document/system-flows.md` § {flow name}
|
||
- `_docs/02_document/deployment/{file}.md` § {section}
|
||
- {add more as needed}
|
||
|
||
## Notes
|
||
|
||
Optional. Use for caveats that did not fit above, links to external research, or follow-ups that the team agreed to revisit on a known trigger ("re-evaluate after 6 months in production" / "re-evaluate when load exceeds 10× baseline").
|