Merged PR 2408: updated context for current state at 19062026
updated context for current state at 19062026 Related work items: #23754
This commit is contained in:
@@ -1,5 +1,33 @@
|
|||||||
# Architecture Reference
|
# Architecture Reference
|
||||||
|
|
||||||
|
## Architecture Programme Status
|
||||||
|
|
||||||
|
### Discovery Status
|
||||||
|
|
||||||
|
Complete
|
||||||
|
|
||||||
|
### Current Phase
|
||||||
|
|
||||||
|
Adoption Planning
|
||||||
|
|
||||||
|
### Current Proven Business Decision Models
|
||||||
|
|
||||||
|
- Appeal Type Policy
|
||||||
|
- Representation Entry Policy
|
||||||
|
- Representation Type Availability
|
||||||
|
|
||||||
|
### Next Recommended Architecture Stream
|
||||||
|
|
||||||
|
Portal API Security & Access Boundary Assessment
|
||||||
|
|
||||||
|
### Objectives
|
||||||
|
|
||||||
|
- endpoint inventory
|
||||||
|
- authenticated/public classification
|
||||||
|
- ownership validation review
|
||||||
|
- access-control consistency review
|
||||||
|
- security boundary assessment
|
||||||
|
|
||||||
## Runtime Topology
|
## Runtime Topology
|
||||||
|
|
||||||
1. Next.js runtime serves UI routes and API routes (legacy custom server files are present but not active).
|
1. Next.js runtime serves UI routes and API routes (legacy custom server files are present but not active).
|
||||||
|
|||||||
@@ -10,6 +10,8 @@ The PEDW architectural discovery programme is considered complete for practical
|
|||||||
|
|
||||||
No strong undiscovered business-policy candidates remain.
|
No strong undiscovered business-policy candidates remain.
|
||||||
|
|
||||||
|
No major undiscovered architectural business-policy candidates remain in the current portal scope.
|
||||||
|
|
||||||
Future architectural work should focus on:
|
Future architectural work should focus on:
|
||||||
|
|
||||||
- documentation consolidation
|
- documentation consolidation
|
||||||
@@ -20,6 +22,8 @@ Future architectural work should focus on:
|
|||||||
|
|
||||||
rather than broad architectural discovery.
|
rather than broad architectural discovery.
|
||||||
|
|
||||||
|
Future architecture work should therefore be treated as adoption-planning and assurance work, not as reopening the discovery programme.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## Final Architectural Classification
|
## Final Architectural Classification
|
||||||
@@ -879,6 +883,21 @@ Primary focus:
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
## Recommended Next Architecture Stream
|
||||||
|
|
||||||
|
Portal API Security & Access Boundary Assessment
|
||||||
|
|
||||||
|
Suggested investigation areas:
|
||||||
|
|
||||||
|
- endpoint inventory
|
||||||
|
- ownership enforcement review
|
||||||
|
- authenticated/public endpoint classification
|
||||||
|
- access-control consistency assessment
|
||||||
|
|
||||||
|
This is intended as the highest-value next architecture stream after discovery close-out and should be treated as a focused security/access-boundary review rather than as a new business-policy discovery track.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
### Recommended Next Verification Slice
|
### Recommended Next Verification Slice
|
||||||
|
|
||||||
**Appeal Type Availability Filtering Verification**
|
**Appeal Type Availability Filtering Verification**
|
||||||
|
|||||||
@@ -1,5 +1,45 @@
|
|||||||
Absolutely — here’s a senior architecture review of this repository.
|
Absolutely — here’s a senior architecture review of this repository.
|
||||||
|
|
||||||
|
## Architecture Programme Outcome (June 2026)
|
||||||
|
|
||||||
|
### Business Decision Models
|
||||||
|
|
||||||
|
- Appeal Type Policy
|
||||||
|
- Representation Entry Policy
|
||||||
|
- Representation Type Availability
|
||||||
|
|
||||||
|
### Presentation Models
|
||||||
|
|
||||||
|
- Dashboard Policy
|
||||||
|
- Case Lifecycle / Journey Interpretation
|
||||||
|
- Welsh Lookup Translation
|
||||||
|
|
||||||
|
### CRM Compatibility Models
|
||||||
|
|
||||||
|
- Query Profiles
|
||||||
|
- CRM Compatibility
|
||||||
|
- Specialist Process Compatibility
|
||||||
|
|
||||||
|
### Workflow / Integration Models
|
||||||
|
|
||||||
|
- Submission Behaviour
|
||||||
|
- Notification Behaviour
|
||||||
|
- New Appeal Start & Resume Behaviour
|
||||||
|
|
||||||
|
### Conclusion
|
||||||
|
|
||||||
|
The architecture increasingly resembles:
|
||||||
|
|
||||||
|
Compatibility Layer
|
||||||
|
↓
|
||||||
|
Adapter Layer
|
||||||
|
↓
|
||||||
|
Business Policy
|
||||||
|
↓
|
||||||
|
Presentation Layer
|
||||||
|
|
||||||
|
rather than large hidden domain models distributed throughout the application.
|
||||||
|
|
||||||
## Update: TASK22211 completed slice (2026-03-23)
|
## Update: TASK22211 completed slice (2026-03-23)
|
||||||
|
|
||||||
- Branch: `TASK22211-endpoint-search-document-contract-consistency`
|
- Branch: `TASK22211-endpoint-search-document-contract-consistency`
|
||||||
|
|||||||
@@ -18,6 +18,43 @@ Follow-ups:
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
### CL-2026-06-19-ARCHITECTURE-PROGRAMME-MILESTONE: discovery close-out and transition to adoption planning
|
||||||
|
|
||||||
|
date: 2026-06-19
|
||||||
|
author: Architecture Review
|
||||||
|
scope: architecture programme
|
||||||
|
type: milestone
|
||||||
|
rationale: Record the conclusion of the architectural discovery programme and the transition into the next architecture phase.
|
||||||
|
impact: Documentation/context only; improves programme clarity, handoff readiness, and next-stream prioritisation; no runtime or implementation behaviour change.
|
||||||
|
status: completed
|
||||||
|
|
||||||
|
Summary:
|
||||||
|
|
||||||
|
Architectural discovery programme concluded.
|
||||||
|
|
||||||
|
Final classifications established:
|
||||||
|
|
||||||
|
- Business Decision Models
|
||||||
|
- Presentation Models
|
||||||
|
- CRM Compatibility Models
|
||||||
|
- Workflow / Integration Models
|
||||||
|
|
||||||
|
Recommendation:
|
||||||
|
|
||||||
|
Transition architecture effort from discovery to adoption planning and API security assessment.
|
||||||
|
|
||||||
|
Validation:
|
||||||
|
|
||||||
|
- Documentation-only update.
|
||||||
|
- No implementation files changed.
|
||||||
|
- No tests or lint run because this was a documentation-only milestone entry.
|
||||||
|
|
||||||
|
Follow-ups:
|
||||||
|
|
||||||
|
- Use Portal API Security & Access Boundary Assessment as the recommended next architecture stream.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
### CL-2026-06-18-CRM-CASE-PROGRESS-CONTEXT: record CRM Case Progress Display investigation conclusions
|
### CL-2026-06-18-CRM-CASE-PROGRESS-CONTEXT: record CRM Case Progress Display investigation conclusions
|
||||||
|
|
||||||
date: 2026-06-18
|
date: 2026-06-18
|
||||||
|
|||||||
@@ -81,3 +81,15 @@ Immediate recommended next lane (aligned to architecture Sequence B):
|
|||||||
- Apply broader logging hardening in auth/file/email/account-sensitive paths.
|
- Apply broader logging hardening in auth/file/email/account-sensitive paths.
|
||||||
|
|
||||||
If you want, I can convert this into a sprint-ready debt register (ID, owner, effort, risk reduction, target milestone).
|
If you want, I can convert this into a sprint-ready debt register (ID, owner, effort, risk reduction, target milestone).
|
||||||
|
|
||||||
|
## 6) Additional architecture visibility debt (2026-06-19)
|
||||||
|
|
||||||
|
### Security Boundary Visibility
|
||||||
|
|
||||||
|
- Inconsistent visibility of endpoint ownership validation.
|
||||||
|
- Unknown consistency of authenticated endpoint protection.
|
||||||
|
- Incomplete inventory of public vs authenticated endpoints.
|
||||||
|
|
||||||
|
Recommended action:
|
||||||
|
|
||||||
|
- Perform Portal API Security & Access Boundary Assessment.
|
||||||
|
|||||||
@@ -122,3 +122,24 @@ Current context:
|
|||||||
- Householder blocked-message suppression
|
- Householder blocked-message suppression
|
||||||
- CPO ended-message / deadline consistency
|
- CPO ended-message / deadline consistency
|
||||||
- missing or conflicting process information handling
|
- 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.
|
||||||
|
|||||||
Reference in New Issue
Block a user