Robert Bond
@@ -18,6 +18,191 @@ Follow-ups:
|
||||
|
||||
---
|
||||
|
||||
### CL-2026-06-29-BUSINESS-DOMAIN-OVERVIEW: clarify PEDW planning-domain terminology and portal business responsibilities
|
||||
|
||||
date: 2026-06-29
|
||||
author: Cline
|
||||
scope: `context/business-domain-overview.md`, `context/architecture.md`, `context/maintainability-adoption-programme.md`, `context/implementation-governance.md`, `memory-bank/change-log.md`
|
||||
type: change
|
||||
rationale: Add a concise business-domain overview so future architectural and implementation work uses correct PEDW planning terminology and clearly distinguishes between digital appeal submission responsibilities and broader statutory public information/public participation responsibilities.
|
||||
impact: Documentation/context only; clarifies business-domain terminology, portal business capabilities, and the relationship between statutory process administration in CRM/PEDW and the portal's public-facing role. No runtime, API, auth/session, CRM, storage, queue, notification, routing, i18n, or behaviour change.
|
||||
status: completed
|
||||
|
||||
Summary:
|
||||
|
||||
- Confirmed the required business-domain clarification context was read before drafting:
|
||||
- `context/architecture.md`
|
||||
- `context/maintainability-adoption-programme.md`
|
||||
- `context/implementation-governance.md`
|
||||
- `GUARDRAILS.md`
|
||||
- `memory-bank/change-log.md`
|
||||
- Created new business-domain clarification document:
|
||||
- `context/business-domain-overview.md`
|
||||
- Recorded the portal's two principal business capabilities as:
|
||||
- Digital Appeal Submission
|
||||
- Statutory Public Information & Public Participation
|
||||
- Clarified that:
|
||||
- digital appeal submission currently applies to supported appeal processes only (currently S78 MVP)
|
||||
- the portal also fulfils statutory public-facing information and participation responsibilities across multiple PEDW-administered case types
|
||||
- CRM / PEDW administers the statutory process
|
||||
- the portal provides the public-facing statutory digital service layer
|
||||
- Added a concise business glossary covering key planning-domain terms including:
|
||||
- Planning Appeal
|
||||
- Planning Application
|
||||
- Planning Case
|
||||
- Appellant
|
||||
- Applicant
|
||||
- Representation
|
||||
- Local Planning Authority (LPA)
|
||||
- DNS
|
||||
- SIP
|
||||
- CRM
|
||||
- PEDW
|
||||
- Updated `context/architecture.md` with a short business-capability context section without altering established architectural classifications.
|
||||
- Updated `context/maintainability-adoption-programme.md` so the programme purpose clearly reflects support for both statutory public information capabilities and current/future supported digital appeal submission capabilities.
|
||||
- Updated `context/implementation-governance.md` with a short clarification that implementation slices should recognise the distinction between digital appeal submission capabilities and statutory public information capabilities.
|
||||
- Left `GUARDRAILS.md` unchanged because no contradiction was identified and no guardrail meaning needed alteration.
|
||||
|
||||
Validation:
|
||||
|
||||
- Documentation-only clarification slice.
|
||||
- No application code or tests changed.
|
||||
- Intended diff-format validation for this slice:
|
||||
- `git diff --check -- context/business-domain-overview.md context/architecture.md context/maintainability-adoption-programme.md context/implementation-governance.md memory-bank/change-log.md`
|
||||
|
||||
Follow-ups:
|
||||
|
||||
- Use `context/business-domain-overview.md` as the business terminology baseline for future architecture and implementation prompts where planning-domain terminology may otherwise be ambiguous.
|
||||
- Keep future workstream and implementation language aligned with the distinction between appeal submission and broader statutory public information responsibilities.
|
||||
|
||||
---
|
||||
|
||||
### CL-2026-06-29-IMPLEMENTATION-GOVERNANCE: create standard execution governance for future maintainability slices
|
||||
|
||||
date: 2026-06-29
|
||||
author: Cline
|
||||
scope: `context/implementation-governance.md`, `context/maintainability-adoption-programme.md`, `GUARDRAILS.md`, `memory-bank/change-log.md`
|
||||
type: change
|
||||
rationale: Create a dedicated governance document defining how future PEDW implementation slices should be planned, branched, executed, validated, documented, and reported, and add minimal linked references so the current programme stage and execution model are clear without reopening discovery.
|
||||
impact: Documentation/context only; defines implementation-slice governance for future maintainability/adoption work, clarifies the relationship between guardrails, architecture phase, and maintainability roadmap, and adds linked references in existing docs. No runtime, API, auth/session, CRM, storage, queue, notification, routing, i18n, or behaviour change.
|
||||
status: completed
|
||||
|
||||
Summary:
|
||||
|
||||
- Confirmed the required governance context was read before drafting:
|
||||
- `GUARDRAILS.md`
|
||||
- `context/maintainability-adoption-programme.md`
|
||||
- `context/architecture.md`
|
||||
- `context/api-grouping-adoption-roadmap.md`
|
||||
- `context/remaining-architecture-candidates.md`
|
||||
- `memory-bank/change-log.md`
|
||||
- `memory-bank/open-questions.md`
|
||||
- Created new governance document:
|
||||
- `context/implementation-governance.md`
|
||||
- Recorded the current programme stage as:
|
||||
- broad architecture discovery complete
|
||||
- business-policy discovery complete
|
||||
- API grouping rollout at a natural boundary for read-style façade slices
|
||||
- maintainability work now implementation-led
|
||||
- future work to proceed through small, behaviour-preserving adoption slices
|
||||
- Defined the standard implementation-slice model as:
|
||||
- one branch
|
||||
- one logical change set
|
||||
- one maintainability workstream
|
||||
- one bounded adoption target
|
||||
- behaviour-preserving unless explicitly approved otherwise
|
||||
- Recorded the required slice lifecycle:
|
||||
- characterize
|
||||
- validate
|
||||
- extract/add
|
||||
- adopt
|
||||
- Recorded branching governance, prompt governance, behaviour-preservation defaults, prohibited-by-default changes, scoped validation expectations, documentation expectations, and required final reporting format.
|
||||
- Updated `context/maintainability-adoption-programme.md` with a short section clarifying that the maintainability programme defines **what** to advance, while implementation governance defines **how** future slices should be executed.
|
||||
- Updated `GUARDRAILS.md` Related Docs with minimal references to:
|
||||
- `context/implementation-governance.md`
|
||||
- `context/maintainability-adoption-programme.md`
|
||||
- Did not update `memory-bank/open-questions.md` because no new unresolved governance question was created by this slice.
|
||||
- Did not create `memory-bank/maintainability-tracker.md` because it does not already exist and was not clearly established as current project convention for this slice.
|
||||
|
||||
Validation:
|
||||
|
||||
- Documentation-only governance slice.
|
||||
- No application code or tests changed.
|
||||
- Intended diff-format validation for this slice:
|
||||
- `git diff --check -- context/implementation-governance.md context/maintainability-adoption-programme.md GUARDRAILS.md memory-bank/change-log.md`
|
||||
|
||||
Follow-ups:
|
||||
|
||||
- Use `context/implementation-governance.md` as the default execution model for future maintainability/adoption implementation prompts.
|
||||
- Keep future slice prompts explicit about workstream, bounded scope, preservation rules, and validation expectations.
|
||||
|
||||
---
|
||||
|
||||
### CL-2026-06-29-MAINTAINABILITY-ADOPTION-PROGRAMME: create architecture roadmap for incremental maintainability implementation workstreams
|
||||
|
||||
date: 2026-06-29
|
||||
author: Cline
|
||||
scope: `context/maintainability-adoption-programme.md`, `memory-bank/change-log.md`
|
||||
type: change
|
||||
rationale: Consolidate the maintainability implementation workstreams that naturally emerged from the completed architecture discovery programme into one planning document so future work can proceed through bounded, behaviour-preserving adoption slices rather than reopening discovery.
|
||||
impact: Documentation/context only; records programme status, maintainability principles, workstream classification, relative priorities, and non-goals for future implementation planning. No runtime, routing, auth/session, CRM, storage, queue, notification, i18n, or behaviour change.
|
||||
status: completed
|
||||
|
||||
Summary:
|
||||
|
||||
- Confirmed the required context was read before drafting the programme document:
|
||||
- `context/architecture.md`
|
||||
- `context/portal-api-platform-assessment.md`
|
||||
- `context/api-grouping-adoption-roadmap.md`
|
||||
- `context/remaining-architecture-candidates.md`
|
||||
- `memory-bank/change-log.md`
|
||||
- Used the completed Bilingual CRM Display Resolution Audit and Bilingual Navigation & Link Resolution Audit as evidence inputs rather than reopening those discovery slices.
|
||||
- Created new planning document:
|
||||
- `context/maintainability-adoption-programme.md`
|
||||
- Recorded the programme position that:
|
||||
- architecture discovery is complete
|
||||
- business-policy discovery is complete
|
||||
- remaining work is implementation-led
|
||||
- future improvements should be incremental and behaviour-preserving
|
||||
- Recorded maintainability principles:
|
||||
- characterize
|
||||
- validate
|
||||
- extract/add
|
||||
- adopt
|
||||
- and explicit prohibitions against rewrite/replace/redesign/modernize without approval
|
||||
- Classified the main maintainability workstreams:
|
||||
- domain layer adoption
|
||||
- CRM display infrastructure
|
||||
- navigation infrastructure
|
||||
- API journey grouping
|
||||
- Recorded for each workstream:
|
||||
- objective
|
||||
- architectural classification
|
||||
- current maturity
|
||||
- implementation strategy
|
||||
- expected maintenance benefit
|
||||
- Recommended relative implementation priority order:
|
||||
1. domain layer adoption
|
||||
2. CRM display infrastructure
|
||||
3. navigation infrastructure
|
||||
4. API journey grouping
|
||||
- Recorded programme-wide guiding principles, explicit non-goals, and the expected adoption model for future bounded slices.
|
||||
|
||||
Validation:
|
||||
|
||||
- Documentation-only planning slice.
|
||||
- Checked consistency against the current architecture phase (`Adoption Planning`), established policy boundaries, API grouping boundary guidance, and completed characterization outputs.
|
||||
- No code, route, contract, or runtime changes performed.
|
||||
- Intended lightweight validation for this slice:
|
||||
- `git diff --check`
|
||||
|
||||
Follow-ups:
|
||||
|
||||
- Use this document as the top-level roadmap when proposing future maintainability implementation slices.
|
||||
- Keep future workstream proposals bounded to one characterized seam and one adoption surface where possible.
|
||||
|
||||
---
|
||||
|
||||
### CL-2026-06-25-WORKFLOW-ORCHESTRATION-DOC-VALIDATION: validate whether existing architecture docs already cover PEDW workflow/orchestration
|
||||
|
||||
date: 2026-06-25
|
||||
|
||||
Reference in New Issue
Block a user