update

ASG_Framework.md

@@ -14,7 +14,7 @@ This document defines the documentation framework for a software project. It est
 | **Specification** | The **technical contract** — precise rules for inputs, outputs, and data shape. Ensures consistency across dev and test. Maps technical implementation to both *what* (requirements) and *how* (solution design). | Developers, QA Engineers, CI/CD pipelines | OpenAPI, Protobuf, AsyncAPI. Endpoint definitions, schemas, error codes. | `contract.yaml` defining a NATS subject (solution-design SD-001.1) that accepts Arrow streams with snake_case headers (requirements FR-001). | 100% of messages validated against spec (CI block rate). |
 | **UI Specification** | The **design contract** — precise rules for UI components, interactions, and visual patterns. Ensures consistency across design and implementation. | Product Designers, Frontend Developers, QA Engineers | Component libraries, style guides, interaction specs, design tokens. | Atomic design system with Figma tokens synced to CSS variables. | 100% of UI components match design spec (visual regression tests). |
 | **Validation** | The **enforcer** — defines tests before implementation begins to ensure spec compliance. Blocks drift and human error. | QA Engineers, Developers, Automation servers | Unit tests, integration tests, performance tests, penetration tests, contract tests, CI jobs, linting rules, schema validation. | CI job rejects PR with camelCase field not allowed by YAML spec. | <1% of PRs bypass validation gates. |
-| **Implementation Plan** | The **execution roadmap** — how implementation is organized, prioritized, and delivered. Maps code to validation tests and specification. | Developers, Project Managers, Lead Developers | Implementation plan, module breakdown, task list, delivery timeline, test strategy. | Phase 1: Core API + data layer; Phase 2: UI components; Phase 3: Integration tests + E2E validation. | 100% of validation tests covered by implementation tasks, <10% timeline drift. |
+| **Implementation Plan** | The **execution roadmap** — how implementation is organized, prioritized, and delivered. Maps code to validation tests and specification. | Developers, Project Managers, Lead Developers | Implementation plan, module breakdown, task list, delivery timeline, test strategy. | Phase 1: Core API + data layer; Phase 2: UI components; Phase 3: Integration tests + E2E validation. | 100% of validation tests covered by implementation tasks. |
 | **Runbook** | The **operational manual** — how the system lives in production, scales, and recovers. Guides on-call engineers. | DevOps, SREs, On-call Developers | K8s manifests, Helm charts, Markdown guides. Deployment, scaling, backup/restore, troubleshooting. | GitOps manifest ensuring 6 Julia replicas restart if memory >80%. | MTTR <15 minutes for P1 incidents. |
 
 ---
@@ -254,11 +254,10 @@ Every traceable item — specification rules (SP-XXX), walkthrough journeys (WT-
 - **Every** specification section with a concrete rule (endpoint, schema field, validation constraint, error code) must have at least one unit test and one contract test — each spec item carries an `SP-XXX` ID
 - **Every** walkthrough journey must have at least one integration test — each walkthrough step carries a `WT-XXX` ID
 - **Every** performance NFR must have at least one performance test (load/stress/benchmark)
-- **Every** security NFR must have at least one penetration test scenario
+- **Every** security NFR must have at least one penetration test scenario and one security scanning test (SAST/dependency checks)
 - **Every** UI component state must have at least one unit test (behavior) and one visual regression test (appearance) — each UI artifact carries a `UI-XXX` ID
 - **Every** data schema must have at least one schema validation test
 - **Every** style guide token must have at least one linting rule
-- **Every** security NFR must have at least one security scanning test (SAST/dependency checks)
 - A test may cover multiple spec items, but each spec item must be covered by **at least one** test
 - Status is tracked via CI gate results (Pass/Fail/Skipped) — not manual checks
 
@@ -406,7 +405,7 @@ Since all docs defined in the ASG Framework are **living documents** that evolve
 |------------------|------|-------------------|-------------|--------|
 | **Requirements → Solution Design** | Turn a "Wish" into a "Solution" | Does the Solution Design clearly explain how the system solves the user problem, not just what it does? | Requirements say "users can compare wines", but solution design only mentions "wine comparison API" without explaining how users will actually use the comparison feature | Add UI flow and user interaction patterns to the solution design |
 | **Solution Design → Walkthrough** | Turn a "Solution" into a "Story" | Does every SD-XXX decision appear in at least one participant's walkthrough section? Is there a WT-XXX ID for every walkthrough step? Is there a section for each system participant? | Solution design defines SD-001 (NATS async messaging), but no participant section traces the async flow | Add an async messaging flow to Participant B section with SD-001 reference and WT-003 ID |
-| **Walkthrough → Specification** | Turn the "Story" into "Rules" | Does the Specification define SP-XXX rules for every WT-XXX walkthrough step? | Walkthrough defines 20 WT-XXX steps across 3 participants, but Specification only has SP-001 through SP-005 (10 items) | Add the missing endpoint definitions, schema rules, and error codes to Specification with SP-006 through SP-020 |
+| **Walkthrough → Specification** | Turn the "Story" into "Rules" | Does every WT-XXX walkthrough step trace to at least one SP-XXX specification rule? | Walkthrough defines 20 WT-XXX steps across 3 participants, but only 10 map to SP-XXX rules | Add SP-XXX rules for the 10 unlinked WT-XXX steps |
 | **Specification → UI Specification** | Turn a "Rule" into a "Button" | Does the UI Specification expose all data entities and states defined in the Specification? Are UI-XXX IDs assigned to every UI artifact? | Specification defines 15 API response schemas with 30 fields, but UI Specification only has 3 components (UI-001 through UI-003) | Add the remaining UI components for each data entity with UI-XXX IDs to match Specification coverage
 | **UI Specification → Validation** | Turn "Design" into "Tests" | Do the Validation tests cover all specification rules, UI states, performance NFRs, and security requirements? | UI Spec defines 15 component states but Validation only has 5 unit tests; NFR-101 latency threshold has no performance test | Add unit tests for all component states, performance benchmarks for NFR thresholds, and pen test scenarios for security NFRs |
 | **Validation → Implementation Plan** | Turn "Tests" into "Tasks" | Does the Implementation Plan satisfy all validation tests with clear ownership? | Validation defines 30 test cases but Implementation Plan only has tasks for 20 | Verify every validation test maps to at least one implementation task with an assignee and timeline |
@@ -483,7 +482,7 @@ Each documentation artifact has associated KPIs. Track these to ensure quality:
 | Specification | Specification compliance rate | 100% of messages validate against spec |
 | UI Specification | UI spec compliance | 100% of components match design spec (visual regression tests) |
 | Validation | Bypass rate | <1% of PRs bypass validation gates |
-| Implementation | Test coverage | >80% unit test coverage |
+| Implementation | Implementation coverage | 100% of validation tests mapped to at least one task |
 | Runbook | MTTR | <15 minutes for P1 incidents |
 
 **Review Cadence**:

etc.md

@@ -1,11 +1,5 @@
-
+8. Lines 11 & 27, 12 & 58 (Purpose)
-
+me: it is ok as-is
-
-
-
-
-
-