Oleksandr Bezdieniezhnykh
1f634c2604
- Modified the autodev state to reflect the current testing phase and details of the new `jetson-e2e` tests. - Enhanced the "How to Test" documentation to provide clearer instructions on the demo replay validation process, including video and tlog alignment steps. - Updated architectural documentation to include the new demo replay operator flow and its dependencies. - Documented the removal of deprecated auto-sync features and clarified the operator-facing UI for replay validation. - Added new entries in the dependencies table for upcoming tasks related to the demo replay flow. These changes improve clarity and usability for operators and developers working with the demo replay system.
3.0 KiB
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").