63 lines
2.7 KiB
Markdown
63 lines
2.7 KiB
Markdown
|
---
|
||
|
|
id: repository-layout/consumer-adoption-brief
|
||
|
|
title: Repository Layout Standard Consumer Adoption Brief
|
||
|
|
status: candidate
|
||
|
|
standard: standard/repository-layout
|
||
|
|
workplan: ITC-WP-0012
|
||
|
|
---
|
||
|
|
|
||
|
|
# Repository Layout Standard Consumer Adoption Brief
|
||
|
|
|
||
|
|
## Purpose
|
||
|
|
|
||
|
|
Use this brief as the seed for adopting the InfoTechCanon Repository Layout
|
||
|
|
Standard in a consumer repository. The adoption and any repo-specific
|
||
|
|
implementation belong in the consumer's own repository, not in InfoTechCanon
|
||
|
|
(same boundary as WP-0009 — `repository scope` is producer-only).
|
||
|
|
|
||
|
|
The layout is a **recommendation, not a strict requirement**. Adopt the parts
|
||
|
|
that fit and declare the conformance level you reach.
|
||
|
|
|
||
|
|
## Canon Inputs
|
||
|
|
|
||
|
|
- `infospace/standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md`
|
||
|
|
- `infospace/evaluations/repository-layout/source-demand.md`
|
||
|
|
- `infospace/evaluations/repository-layout/placement-decision.yaml`
|
||
|
|
- `infospace/evaluations/repository-layout/reconciliation.yaml`
|
||
|
|
- `infospace/models/governance/InfoTechCanonPurposeDemandExtension.md`
|
||
|
|
- `infospace/patterns/intent-scope-purposes.md`
|
||
|
|
|
||
|
|
## Adoption Steps For A Consumer Repo
|
||
|
|
|
||
|
|
1. Add `INTENT.md` and `SCOPE.md` at the repository root, keeping intent
|
||
|
|
(aspiration) and scope (current boundary) distinct — do not collapse them.
|
||
|
|
2. Decide which canonical directories the repo needs from the set
|
||
|
|
`research/ demand/ spec/ workplans/ docs/ wiki/ issues/ history/`, mapping
|
||
|
|
each to the canon model it references (Information Space, Governance,
|
||
|
|
Purpose/Demand, Task) rather than redefining those concepts.
|
||
|
|
3. Route un-reviewed inbound through `demand/`; promote to `workplans/` only
|
||
|
|
after a review/decision trail (no demand-as-task).
|
||
|
|
4. Apply the `yymmdd-` prefix in `research/` and `history/` so explorations and
|
||
|
|
archives stay chronologically retrievable.
|
||
|
|
5. Adopt the SCOPE→INTENT operating mode: work = closing the gap from current
|
||
|
|
SCOPE to target INTENT, refining both as learning accrues.
|
||
|
|
6. Declare a `LayoutConformanceLevel` (`minimal` / `core` / `full`) for the repo
|
||
|
|
and record which directories are intentionally omitted.
|
||
|
|
|
||
|
|
## Expected Outputs (in the consumer repo)
|
||
|
|
|
||
|
|
- root `INTENT.md` and `SCOPE.md`,
|
||
|
|
- the chosen canonical directories in use as defined,
|
||
|
|
- a declared conformance level,
|
||
|
|
- a short note on intentional omissions and any repo-specific deviations.
|
||
|
|
|
||
|
|
## Non-Goals
|
||
|
|
|
||
|
|
- Do not modify the Repository Layout Standard from a consumer workplan without a
|
||
|
|
canon-side EvolutionRequest.
|
||
|
|
- Do not treat the layout as mandatory; partial conformance is valid.
|
||
|
|
- Do not let `spec/` or `docs/` silently redefine `SCOPE.md`; scope changes
|
||
|
|
belong in `SCOPE.md` under governance.
|
||
|
|
- Do not edit `issues/` as if it were the ticket system of record (it is a
|
||
|
|
mirror).
|