docs: add current-state context pack and actionable sequence-b prompts
This commit is contained in:
@@ -29,13 +29,20 @@ impact: Potential privacy/security exposure via operational logs.
|
||||
status: open
|
||||
|
||||
Question:
|
||||
What mandatory redaction and logging policy should be enforced for auth/email/document flows?
|
||||
What mandatory redaction and structured logging policy should be enforced for auth/email/document flows (fields blocked, allowed metadata, and incident correlation expectations)?
|
||||
|
||||
Needed from:
|
||||
Security lead + application owner
|
||||
|
||||
Decision deadline:
|
||||
Before next auth/notification release
|
||||
Before Sequence B Workstream B2 rollout
|
||||
|
||||
Current context:
|
||||
|
||||
- Relay logging policy has already been hardened in middleware, but auth/email/file routes still have uneven logging style.
|
||||
- Reference planning docs:
|
||||
- `context/next-work-plan-sequence-b.md`
|
||||
- `context/current-state-scorecard.md`
|
||||
|
||||
### Q-002: Test Strategy Baseline for Sparse `tests/`
|
||||
|
||||
@@ -48,10 +55,36 @@ impact: Increased regression risk and slower release confidence.
|
||||
status: open
|
||||
|
||||
Question:
|
||||
What minimum automated coverage should be required per change type (feature, bug fix, high-risk integration)?
|
||||
What minimum automated coverage should be required per change type (feature, bug fix, high-risk integration), and which suites become mandatory CI gates?
|
||||
|
||||
Needed from:
|
||||
Engineering lead + QA
|
||||
|
||||
Decision deadline:
|
||||
Before next major feature cycle
|
||||
Before enabling Sequence C CI parity gate rollout
|
||||
|
||||
Current context:
|
||||
|
||||
- Focused high-risk automation exists in phase21/phase22 (auth redirect, i18n route parity, relay hardening, endpoint contract slices).
|
||||
- A formal CI baseline decision is still needed to institutionalize these checks.
|
||||
|
||||
---
|
||||
|
||||
### Q-003: Runtime canonical startup path selection
|
||||
|
||||
date: 2026-03-25
|
||||
author: Cline
|
||||
scope: runtime startup path and operational documentation
|
||||
type: question
|
||||
rationale: Dual server entrypoints (`server.js` and `server/server.js`) remain a known architecture ambiguity in review artifacts.
|
||||
impact: Operational ambiguity can increase deployment and incident-response risk.
|
||||
status: open
|
||||
|
||||
Question:
|
||||
Which startup path is canonical for dev/test/prod, and what is the deprecation plan for the non-canonical entrypoint?
|
||||
|
||||
Needed from:
|
||||
Technical lead + DevOps owner
|
||||
|
||||
Decision deadline:
|
||||
Before runtime-affecting refactor or next deployment process update
|
||||
|
||||
Reference in New Issue
Block a user