auto: daily sync
This commit is contained in:
37
docs/guides/DOCUMENTATION_BOUNDARIES.md
Normal file
37
docs/guides/DOCUMENTATION_BOUNDARIES.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# Documentation Boundaries (Atomizer Standard)
|
||||
|
||||
## Rule
|
||||
- **Project-specific content** belongs in `projects/<project-name>/...`
|
||||
- **Foundational / reusable content** belongs in `docs/...`
|
||||
|
||||
This is a hard rule for all agents.
|
||||
|
||||
## What is project-specific?
|
||||
Store in `projects/...`:
|
||||
- Run logs, experiment outcomes, project decisions
|
||||
- Project playbooks tied to one geometry/client/study
|
||||
- Project troubleshooting notes and sync incidents
|
||||
- Project KPIs, deliverables, and channel-specific context
|
||||
|
||||
## What is foundational?
|
||||
Store in `docs/...`:
|
||||
- Generic workflows used by multiple projects
|
||||
- Platform-level operator guides
|
||||
- Reusable run/checklist templates
|
||||
- Protocols and standards
|
||||
- Cross-project troubleshooting procedures
|
||||
|
||||
## Ownership
|
||||
- **Manager owns documentation quality and structure.**
|
||||
- Drafting can be delegated, but final responsibility remains with Manager.
|
||||
|
||||
## Operating procedure
|
||||
When writing docs:
|
||||
1. Decide: project-specific or foundational.
|
||||
2. Write in the correct location first (no temporary drift).
|
||||
3. If a project doc becomes reusable, promote a generalized version into `docs/...` and keep project examples in the project folder.
|
||||
4. Cross-link both locations when useful.
|
||||
|
||||
## Current Hydrotech application
|
||||
- Hydrotech run/playbook files remain in `projects/hydrotech-beam/...`.
|
||||
- Reusable standards from Hydrotech are promoted into `docs/guides/...` as they stabilize.
|
||||
48
docs/guides/PKM_DASHBOARD_STANDARD.md
Normal file
48
docs/guides/PKM_DASHBOARD_STANDARD.md
Normal file
@@ -0,0 +1,48 @@
|
||||
# PKM Dashboard Standard (Atomizer)
|
||||
|
||||
## Purpose
|
||||
Standardize how project dashboards and reports are built across Atomizer.
|
||||
|
||||
## Core Standard
|
||||
1. **Contracts-first:** every metric must map to structured source records.
|
||||
2. **Markdown-first:** default delivery is markdown snapshots.
|
||||
3. **Role-based views:** Executive, Technical, Operations.
|
||||
4. **Governance-first:** clear owner, schema validation, gate policy.
|
||||
|
||||
## Directory split
|
||||
- Project-specific: `projects/<project>/...`
|
||||
- Foundational: `docs/...`
|
||||
|
||||
## Minimum required artifacts per project
|
||||
- `dashboard/MASTER_PLAN.md`
|
||||
- `dashboard/EXECUTIVE_DASHBOARD.md`
|
||||
- `dashboard/TECHNICAL_DASHBOARD.md`
|
||||
- `dashboard/OPERATIONS_DASHBOARD.md`
|
||||
- `reports/` (daily/weekly/gate)
|
||||
- `runs/` manifests
|
||||
- `decisions/` append-only log
|
||||
- `incidents/` append-only log
|
||||
|
||||
## Minimum required contracts
|
||||
- `run_manifest.v1`
|
||||
- `study_summary.v1`
|
||||
- `trial_result.v1`
|
||||
- `decision_record.v1`
|
||||
- `risk_record.v1`
|
||||
- `gate_evaluation.v1`
|
||||
- `incident_record.v1`
|
||||
|
||||
## Gate semantics
|
||||
- `PASS` / `CONDITIONAL_PASS` / `FAIL`
|
||||
- `FAIL` blocks progression
|
||||
- `CONDITIONAL_PASS` requires owner + due date + explicit acceptance
|
||||
|
||||
## Quality controls
|
||||
- Ingestion schema validation
|
||||
- Nightly integrity checks
|
||||
- Freshness SLA checks
|
||||
- Auditor spot checks
|
||||
|
||||
## Evolution policy
|
||||
- Start markdown-native
|
||||
- Add richer visual layer only over same contracts (no parallel truth)
|
||||
Reference in New Issue
Block a user