51 lines
3.9 KiB
Markdown
51 lines
3.9 KiB
Markdown
# Standards Overview
|
|
|
|
This section contains technical, documentation, and business standards.
|
|
|
|
## Current State
|
|
|
|
No formal standards documents have been published yet. The following standards are applied implicitly through existing architecture, operations, and development documentation but have not been formalized as controlled standards documents.
|
|
|
|
## Recommended Standards
|
|
|
|
The following standards were identified through project analysis as candidates for formal documentation. Each aligns to the policy repository naming convention (`KC-STD-<DOMAIN>-<NUMBER>`) and can be created using the standard template at `policies/templates/standard-template.md`.
|
|
|
|
### Documentation standards
|
|
|
|
| Candidate ID | Title | Priority | Notes |
|
|
| -------------- | ------------------------------------------ | -------- | ----------------------------------------------------------------------------------------------------------------- |
|
|
| KC-STD-GOV-001 | Documentation Naming and Metadata Standard | High | Formalize the YAML front matter requirements already defined in the policy repository README |
|
|
| KC-STD-GOV-002 | Architecture Documentation Standard | Medium | Formalize the C4 diagram documentation pattern (purpose, diagram source, diagram, elements, notes) already in use |
|
|
| KC-STD-IT-001 | Markdown Authoring Standard | Low | Formalize linting rules (`.markdownlint.json`), heading conventions, and link patterns |
|
|
|
|
### Development standards
|
|
|
|
| Candidate ID | Title | Priority | Notes |
|
|
| ------------- | ---------------------------------- | -------- | ---------------------------------------------------------------------------------------------------- |
|
|
| KC-STD-IT-002 | Flutter Package Structure Standard | High | Formalize the domain/application/data/presentation layer pattern used across feature packages |
|
|
| KC-STD-IT-003 | Test Coverage Standard | Medium | Formalize baseline coverage expectations and reporting; currently visibility-only with no thresholds |
|
|
| KC-STD-IT-004 | Git Branching and Merge Standard | Medium | Formalize the `feat/` branch-per-slice model and PR requirements documented in the development brief |
|
|
| KC-STD-IT-005 | CI/CD Workflow Standard | Low | Formalize workflow naming, trigger patterns, and runner label conventions |
|
|
|
|
### Business standards
|
|
|
|
| Candidate ID | Title | Priority | Notes |
|
|
| -------------- | -------------------------------- | -------- | ------------------------------------------------------ |
|
|
| KC-STD-MKT-001 | Social Media Publishing Standard | Low | Referenced in the traceability index as a coverage gap |
|
|
| KC-STD-ECM-001 | Product Publishing Standard | Low | Referenced in the traceability index as a coverage gap |
|
|
| KC-STD-OPS-001 | Inventory Adjustment Standard | Low | Referenced in the traceability index as a coverage gap |
|
|
|
|
## Prioritization
|
|
|
|
Standards should be prioritized based on:
|
|
|
|
1. **Risk reduction** — Does this standard prevent inconsistency or errors?
|
|
2. **Existing practice** — Is the standard already followed informally?
|
|
3. **Scope of impact** — How many areas of the platform does it affect?
|
|
|
|
The documentation and development standards are recommended first because they codify practices already in use and reduce the risk of drift as the platform grows.
|
|
|
|
## Relationship to Policies and Procedures
|
|
|
|
Standards define measurable requirements and constraints. They are governed by the Document Control Policy (`KC-POL-GOV-001`) and follow the same controlled lifecycle (draft → review → active → retired).
|