generated from coulomb/repo-seed
tegwick
f7ad73d9da
Register the InfoTechCanon Repository Layout Standard as a domain standard (itc-repo-layout), processed from demand through the canon's Purpose/Demand intake without collapsing existing model concepts. - Register standard in artifacts/index.yaml, canon.yaml, infospace.yaml; regenerate indexes, views, briefs, tree, and validation (validate green). - T04: add reconciliation.yaml (partial/as-is dogfooding, declared core conformance, recorded tensions); resolve the demand by moving it out of demand/ to the evaluation pack as source-demand.md and removing demand/. - T05: add consumer-adoption-brief.md for downstream repos. - Update test artifact/standard counts (60->61, standards 2->3). - Mark T03/T04/T05 done; workplan and registry status -> finished. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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).
|