146 lines
4.7 KiB
Markdown
146 lines
4.7 KiB
Markdown
# 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
|
|
|
|
---
|
|
|
|
### Q-004: Representation Participation Availability business validation
|
|
|
|
date: 2026-06-18
|
|
author: Cline
|
|
scope: representation participation availability across summary/search/domain policy
|
|
type: question
|
|
rationale: Technical characterization is complete, but several compatibility-sensitive behaviours may be historical rather than intentional and need business confirmation before any further representation-policy adoption or behaviour change work.
|
|
impact: User-facing participation availability, blocked messaging, cross-portal consistency, and future domain-boundary decisions.
|
|
status: open
|
|
|
|
Question:
|
|
Which current representation participation behaviours are intended business rules, and which are historical compatibility behaviours only?
|
|
|
|
Needed from:
|
|
Product owner + business analyst + relevant SME/CRM data owner
|
|
|
|
Decision deadline:
|
|
Before any further representation-policy adoption, expansion, normalization, or behavioural change work
|
|
|
|
Current context:
|
|
|
|
- Technical characterization and documentation are now recorded in:
|
|
- `docs/representation-participation-availability.md`
|
|
- `docs/representation-participation-business-review.md`
|
|
- Business validation is especially needed for:
|
|
- Rights of Way behaviour when process information is incomplete or stored differently
|
|
- Advertisement behaviour when process information is incomplete or conflicting
|
|
- whether all portal areas should behave consistently
|
|
- Householder blocked-message suppression
|
|
- CPO ended-message / deadline consistency
|
|
- missing or conflicting process information handling
|
|
|
|
---
|
|
|
|
### Q-005: Portal API Security Boundary Assessment
|
|
|
|
date: 2026-06-19
|
|
author: Architect Review
|
|
scope: API endpoints and ownership enforcement
|
|
type: question
|
|
rationale: Discovery programme complete. Security/access boundary review identified as the highest-value architecture stream.
|
|
impact: security, privacy, maintainability
|
|
status: open
|
|
|
|
Question:
|
|
What is the current ownership-validation and access-control posture across public and authenticated API endpoints?
|
|
|
|
Needed from:
|
|
Architecture review stream
|
|
|
|
Decision deadline:
|
|
Before major domain-layer adoption or API modernization work.
|