refactor(docs): move requirements and test infra docs into docs/ subdirectories
Organize documentation by moving requirements (HighLevelReqs, Component-*, lmxproxy_protocol) to docs/requirements/ and test infrastructure docs to docs/test_infra/. Updates all cross-references in README, CLAUDE.md, infra/README, component docs, and 23 plan files.
This commit is contained in:
Joseph Doherty
@@ -36,7 +36,7 @@ Specifically required from earlier phases:
|
||||
|
||||
## 3. Requirements Checklist
|
||||
|
||||
Each bullet extracted from HighLevelReqs.md sections covered by this phase. IDs follow the pattern `[section-N]`.
|
||||
Each bullet extracted from docs/requirements/HighLevelReqs.md sections covered by this phase. IDs follow the pattern `[section-N]`.
|
||||
|
||||
### 3.1 Template Structure
|
||||
- `[3.1-1]` Machines are modeled as instances of templates.
|
||||
@@ -174,7 +174,7 @@ Each bullet extracted from HighLevelReqs.md sections covered by this phase. IDs
|
||||
|
||||
## 4. Design Constraints Checklist
|
||||
|
||||
Constraints from CLAUDE.md Key Design Decisions and Component-TemplateEngine.md / Component-ConfigurationDatabase.md.
|
||||
Constraints from CLAUDE.md Key Design Decisions and docs/requirements/Component-TemplateEngine.md / docs/requirements/Component-ConfigurationDatabase.md.
|
||||
|
||||
### From CLAUDE.md Key Design Decisions
|
||||
|
||||
@@ -186,7 +186,7 @@ Constraints from CLAUDE.md Key Design Decisions and Component-TemplateEngine.md
|
||||
- `[KDD-deploy-10]` Last-write-wins for concurrent template editing (no optimistic concurrency on templates).
|
||||
- `[KDD-deploy-12]` Naming collisions in composed feature modules are design-time errors.
|
||||
|
||||
### From Component-TemplateEngine.md
|
||||
### From docs/requirements/Component-TemplateEngine.md
|
||||
|
||||
- `[CD-TE-1]` Template has unique name/ID.
|
||||
- `[CD-TE-2]` Template cannot be deleted if referenced by instances or child templates.
|
||||
@@ -215,7 +215,7 @@ Constraints from CLAUDE.md Key Design Decisions and Component-TemplateEngine.md
|
||||
- `[CD-TE-25]` Script has trigger configuration: Interval, Value Change, Conditional, or invoked by alarm/other script.
|
||||
- `[CD-TE-26]` Script has optional minimum time between runs.
|
||||
|
||||
### From Component-ConfigurationDatabase.md
|
||||
### From docs/requirements/Component-ConfigurationDatabase.md
|
||||
|
||||
- `[CD-CDB-1]` ITemplateEngineRepository covers: templates, attributes, alarms, scripts, compositions, instances, overrides, connection bindings, areas.
|
||||
- `[CD-CDB-2]` IDeploymentManagerRepository covers: current deployment status per instance, deployed configuration snapshots, system-wide artifact deployment status per site.
|
||||
@@ -488,11 +488,11 @@ Constraints from CLAUDE.md Key Design Decisions and Component-TemplateEngine.md
|
||||
|
||||
**Acceptance Criteria**:
|
||||
- Resolution order: Instance → Child Template (most derived first) → Composing Template → Composed Module (recursively). (`[3.6R-1]`, `[3.6R-2]`)
|
||||
- Walk inheritance chain applying overrides at each level, respecting locks. (Component-TE flattening step 2)
|
||||
- Resolve composed feature modules, applying overrides from composing templates, respecting locks. (Component-TE flattening step 3)
|
||||
- Apply instance-level overrides, respecting locks. (Component-TE flattening step 4)
|
||||
- Walk inheritance chain applying overrides at each level, respecting locks. (docs/requirements/Component-TE flattening step 2)
|
||||
- Resolve composed feature modules, applying overrides from composing templates, respecting locks. (docs/requirements/Component-TE flattening step 3)
|
||||
- Apply instance-level overrides, respecting locks. (docs/requirements/Component-TE flattening step 4)
|
||||
- Resolve data connection bindings — replace connection name references with concrete connection details from site. (`[3.3-8]`, `[CD-TE-11]`)
|
||||
- Output a flat structure: list of attributes with resolved values and data source addresses, list of alarms with resolved trigger definitions, list of scripts with resolved code and triggers. (Component-TE flattening step 6)
|
||||
- Output a flat structure: list of attributes with resolved values and data source addresses, list of alarms with resolved trigger definitions, list of scripts with resolved code and triggers. (docs/requirements/Component-TE flattening step 6)
|
||||
- Flattening success is a pre-deployment validation check. (`[3.11-1]`)
|
||||
- Test: multi-level inheritance with overrides and locks → correct resolution.
|
||||
- Test: nested composition with overrides → correct canonical names.
|
||||
@@ -547,7 +547,7 @@ Constraints from CLAUDE.md Key Design Decisions and Component-TemplateEngine.md
|
||||
|
||||
**Acceptance Criteria**:
|
||||
- Deployment package format is explicitly defined and versioned.
|
||||
- Package contains: all resolved attributes (values, data types, data source addresses with connection details), all resolved alarms (trigger definitions with resolved attribute references), all resolved scripts (source code, trigger configuration, parameter/return definitions). (Component-TE flattening step 6)
|
||||
- Package contains: all resolved attributes (values, data types, data source addresses with connection details), all resolved alarms (trigger definitions with resolved attribute references), all resolved scripts (source code, trigger configuration, parameter/return definitions). (docs/requirements/Component-TE flattening step 6)
|
||||
- Package includes the revision hash. (`[KDD-deploy-5]`)
|
||||
- Scripts are included for deployment to sites as part of flattened config. (`[4.1-3]`)
|
||||
- Pre-compilation validation occurs at central; actual compilation at site. (`[4.1-4]`)
|
||||
@@ -671,7 +671,7 @@ Constraints from CLAUDE.md Key Design Decisions and Component-TemplateEngine.md
|
||||
**Description**: Implement the EF Core repository for all template domain entities.
|
||||
|
||||
**Acceptance Criteria**:
|
||||
- Repository covers: templates, attributes, alarms, scripts, compositions, instances, overrides, connection bindings, areas. (`[CD-CDB-1]`) Note: shared scripts (`[CD-CDB-7]`) may be added to this repository or served by a separate interface — decide during implementation. The Component-ConfigurationDatabase.md scope for ITemplateEngineRepository does not explicitly include shared scripts; if a separate interface is warranted, create one.
|
||||
- Repository covers: templates, attributes, alarms, scripts, compositions, instances, overrides, connection bindings, areas. (`[CD-CDB-1]`) Note: shared scripts (`[CD-CDB-7]`) may be added to this repository or served by a separate interface — decide during implementation. The docs/requirements/Component-ConfigurationDatabase.md scope for ITemplateEngineRepository does not explicitly include shared scripts; if a separate interface is warranted, create one.
|
||||
- Implementation uses DbContext internally with POCO entities from Commons. (`[CD-CDB-5]`)
|
||||
- Consuming components depend only on Commons interfaces. (`[CD-CDB-6]`)
|
||||
- Unit-of-work support: multiple operations commit in a single transaction.
|
||||
@@ -1096,7 +1096,7 @@ Codex MCP external verification was performed using model `gpt-5.4`. The review
|
||||
2. **3.9 individual-instance deployment bullet not extracted** — Added `[3.9-6]` to Requirements Checklist. Split-section check updated.
|
||||
3. **System-wide artifact deployment status in WP-24** — WP-24 is a stub; system-wide artifact deployment status is Phase 3C scope. Accepted as-is (stub level sufficient for Phase 2).
|
||||
4. **Instance lifecycle concurrency missing from WP-20** — Added optimistic concurrency via rowversion to WP-20 acceptance criteria. Updated `[CD-CDB-4]` forward trace.
|
||||
5. **Shared scripts repository assignment** — Clarified in WP-5 and WP-23 that shared scripts may use ITemplateEngineRepository or a separate interface; the Component-ConfigurationDatabase.md ITemplateEngineRepository scope does not explicitly include shared scripts.
|
||||
5. **Shared scripts repository assignment** — Clarified in WP-5 and WP-23 that shared scripts may use ITemplateEngineRepository or a separate interface; the docs/requirements/Component-ConfigurationDatabase.md ITemplateEngineRepository scope does not explicitly include shared scripts.
|
||||
6. **"No rollback" vs deployment history records** — Clarified in WP-15 and `[3.9-4]` that "no rollback" means no rollback mechanism/operation, not absence of deployment history records. Deployment records exist for audit per Configuration Database schema.
|
||||
7. **Composition deletion constraint in WP-25** — Added clarifying note that composed-template deletion constraint is a logical implication of `[CD-TE-2]` (stricter but consistent interpretation).
|
||||
|
||||
@@ -1112,6 +1112,6 @@ Codex MCP external verification was performed using model `gpt-5.4`. The review
|
||||
12. **`[3.11-8]` Central UI / Design role not verified in WP-18** — Dismissed. Phase 2 provides the on-demand validation API. The Central UI integration and Design role enforcement for the validation UI are Phase 5 concerns. WP-18 correctly verifies the pipeline can be invoked without deployment; UI wiring is out of scope.
|
||||
13. **`[4.5-3]` Design role gating** — Partially addressed: added Design role enforcement note to WP-5. Full UI-level role enforcement is Phase 5.
|
||||
14. **`[CD-TE-9]` stream topics and UI display not verified** — Dismissed. Stream topics are Phase 3B (Akka stream); UI display is Phase 5. Phase 2 covers canonical names in triggers, scripts, and diffs which are the Phase 2 concern.
|
||||
15. **Naming collision with canonical names contradicts HLR** — Dismissed. The HighLevelReqs statement "two feature modules that each define an attribute with the same name" is refined by Component-TemplateEngine.md which introduces canonical naming with module instance name prefixes. The component design is authoritative for implementation details; the HLR describes the user-facing intent (collisions are errors) while the component design specifies the mechanism (canonical names prevent false collisions). No contradiction — the component design is a refinement.
|
||||
15. **Naming collision with canonical names contradicts HLR** — Dismissed. The HighLevelReqs statement "two feature modules that each define an attribute with the same name" is refined by docs/requirements/Component-TemplateEngine.md which introduces canonical naming with module instance name prefixes. The component design is authoritative for implementation details; the HLR describes the user-facing intent (collisions are errors) while the component design specifies the mechanism (canonical names prevent false collisions). No contradiction — the component design is a refinement.
|
||||
|
||||
**Status**: Pass with corrections. All findings either addressed in the plan or dismissed with rationale.
|
||||
|
||||
Reference in New Issue
Block a user