# Open Questions

## Entry Template

```
date: YYYY-MM-DD
author: <agent|name>
scope: <files/routes/features>
type: question
rationale: <why unresolved>
impact: <user/system/security/i18n/a11y>
status: open|resolved

Question:
Needed from:
Decision deadline:
```

---

### Q-001: Auth Logging Redaction Standard

date: 2026-03-11  
author: Cline  
scope: auth/email APIs and actions logging  
type: question  
rationale: Existing logging appears verbose in sensitive flows.  
impact: Potential privacy/security exposure via operational logs.  
status: open

Question:
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 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/`

date: 2026-03-11  
author: Cline  
scope: testing strategy repository-wide  
type: question  
rationale: `tests/` currently appears minimal; validation relies heavily on manual checks.  
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), and which suites become mandatory CI gates?

Needed from:
Engineering lead + QA

Decision deadline:
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