pedwfrontend/context/next-work-plan-sequence-b.md

Sequence B Work Plan (2026-03-25)

Scope: implement the next architecture lane after Sequence A completion.

Sequence B objectives:

1. Consolidate signed-request patterns.
2. Harden logging policy in sensitive paths.

Workstream B1: Signed-request consolidation

Goal

Reduce duplicate hash/header/method composition logic across service modules without changing behavior contracts.

Target scope

• actions/services/portalDirectService.js
• actions/services/documentDirectService.js
• actions/services/caseDirectService.js (if signed routes exist)
• shared client layer in actions/clients/

Proposed implementation

1. Introduce a focused signed-request helper (or helper set) in actions/clients/:
   • signed GET
   • signed POST
   • signed DELETE
2. Normalize hash/signing + header behavior through helper API.
3. Migrate in bounded slices (module by module), preserving current catch semantics.

Acceptance criteria

• No route URL/signature behavior regressions.
• Existing signed flows preserve:
  • hash generation behavior
  • request method
  • required headers
  • error-return/catch contracts.
• Phase22 behavioural tests expanded where relevant.

Validation checklist

• node tests/phase22/index.test.cjs
• node tests/phase7/service-behaviour.test.cjs
• npm run lint

Rollback plan

• Revert helper adoption commit(s) for affected service only.
• Keep migrations bounded so each module rollback is isolated.

Workstream B2: Logging hardening in sensitive paths

Goal

Replace ad-hoc verbose logging in auth/email/file/account-sensitive paths with redacted, structured logs.

Target scope

• pages/api/auth/[...nextauth].js
• selected pages/api/email/**
• selected pages/api/file/**
• any adjacent shared helper used by these routes

Proposed implementation

1. Define/confirm minimal redaction policy (link to memory-bank/open-questions.md Q-001).
2. Introduce/standardize structured logger usage pattern for sensitive flows.
3. Replace high-risk direct logs in bounded route clusters.

Acceptance criteria

• No secrets/tokens/personal data in new logs.
• Error correlation remains operationally useful.
• Existing route behavior/contracts unchanged.

Validation checklist

• npm run lint
• targeted route-level negative-path checks for changed handlers
• manual review of log payload fields against redaction policy

Rollback plan

• Revert logging-hardening commit(s) by cluster.
• Restore previous logger call sites if operational diagnostics regress.

Delivery sequencing

1. B1 signed-request helper design + one pilot migration.
2. B1 full module rollout (portal/document, then any remaining signed paths).
3. B2 redaction policy confirmation.
4. B2 auth cluster hardening.
5. B2 file/email cluster hardening.

Ownership and governance

• Track each slice in memory-bank/change-log.md.
• Record policy decisions in memory-bank/decisions.md.
• Escalate unresolved policy questions in memory-bank/open-questions.md.