generated from coulomb/repo-seed
ITC-WP-0012: integrate Repository Layout Standard
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>
This commit is contained in:
163
infospace/evaluations/repository-layout/placement-decision.yaml
Normal file
163
infospace/evaluations/repository-layout/placement-decision.yaml
Normal file
@@ -0,0 +1,163 @@
|
||||
id: demand/repository-layout/placement-decision
|
||||
title: Canonical Repository Layout Placement Decision
|
||||
status: reviewed
|
||||
type: placement-decision
|
||||
review_gate: ITC-WP-0012-T02
|
||||
uses:
|
||||
- model/purpose-demand-extension
|
||||
- model/governance
|
||||
inputs:
|
||||
demand_intake: infospace/evaluations/repository-layout/demand-intake.yaml
|
||||
source_artifact: infospace/evaluations/repository-layout/source-demand.md
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Decision: where does this convention belong in the canon line of structures?
|
||||
# ---------------------------------------------------------------------------
|
||||
decision:
|
||||
placement: standard
|
||||
proposed_id: itc-repo-layout
|
||||
proposed_title: InfoTechCanonRepositoryLayoutStandard
|
||||
proposed_path: infospace/standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md
|
||||
conformance_posture: recommendation
|
||||
rationale: >-
|
||||
The proposal is a named, cross-cutting documentation convention that spans
|
||||
several existing models without redefining any of them — the canon's own
|
||||
definition of a Standard ("cross-cutting conventions or named analytical/
|
||||
design frameworks", canon.yaml classification). It is a sibling to the
|
||||
Tagging and CARING standards, not a domain model (it introduces no new domain
|
||||
entities), not a profile (it is not a concrete proof of a model against a
|
||||
scenario), and not a pattern (it prescribes a directory contract, not a
|
||||
reusable solution shape). The source is explicit that it is a recommendation,
|
||||
so conformance is graded, not mandatory.
|
||||
rejected_alternatives:
|
||||
- placement: model
|
||||
why_not: >-
|
||||
Would imply new domain concepts the canon must own permanently; the
|
||||
convention instead references concepts already owned by Information
|
||||
Space, Governance, Purpose/Demand, and Task.
|
||||
- placement: profile
|
||||
why_not: >-
|
||||
Profiles are concrete proofs of models against a scenario (e.g.
|
||||
small-saas); a repository documentation layout is a general convention,
|
||||
not a scenario proof.
|
||||
- placement: pattern
|
||||
why_not: >-
|
||||
Patterns capture a context/problem/solution shape (e.g.
|
||||
intent-scope-purposes); the demand is a prescriptive directory set and
|
||||
operating mode, which reads as a standard, not a pattern. The standard
|
||||
may cite the intent-scope-purposes pattern.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Ownership map: each layout element points at the model that already owns the
|
||||
# concepts it relies on. The standard REFERENCES these; it must not redefine.
|
||||
# ---------------------------------------------------------------------------
|
||||
ownership_map:
|
||||
- element: "INTENT.md / SCOPE.md + SCOPE->INTENT gap-closing operating mode"
|
||||
owned_by:
|
||||
- model/governance
|
||||
- model/purpose-demand-extension
|
||||
- pattern/intent-scope-purposes
|
||||
note: >-
|
||||
INTENT/SCOPE/PURPOSES distinction and the gap-closing loop are already
|
||||
owned. The standard cites them and locates them as repo-root files.
|
||||
no_collapse: Keep INTENT vs SCOPE vs PURPOSES distinct.
|
||||
- element: "demand/"
|
||||
owned_by:
|
||||
- model/purpose-demand-extension
|
||||
note: >-
|
||||
The raw inbound surface for DemandSignal capture before review. This very
|
||||
workplan dogfooded it (demand/CanonicalRepositoryLayout.md).
|
||||
no_collapse: demand/ holds un-reviewed DemandSignals, not Tasks.
|
||||
- element: "research/"
|
||||
owned_by:
|
||||
- model/information-space
|
||||
note: >-
|
||||
Exploration results in problem/solution space; yymmdd-prefixed. Knowledge
|
||||
packaging and retrieval are Information Space concerns.
|
||||
- element: "spec/ (PRD / TechSpec / UseCaseCatalog / ArchitectureBlueprint)"
|
||||
owned_by:
|
||||
- model/governance
|
||||
- model/information-space
|
||||
note: >-
|
||||
Specs provide guardrails (Governance directive surface) packaged as
|
||||
retrievable knowledge (Information Space). Doc-type background lives in the
|
||||
InfoTechPrimers space on coulomb.social (external reference).
|
||||
- element: "workplans/"
|
||||
owned_by:
|
||||
- model/task
|
||||
note: >-
|
||||
Workplans carry Tasks, registered with the State Hub. Task Model owns
|
||||
backlog/readiness/commitment/progress/completion semantics.
|
||||
no_collapse: Workplan/Task are work structure; demand/ is pre-work.
|
||||
- element: "docs/"
|
||||
owned_by:
|
||||
- model/information-space
|
||||
note: Stakeholder-facing documentation (users, developers, humans, agents).
|
||||
- element: "wiki/"
|
||||
owned_by:
|
||||
- model/information-space
|
||||
note: Interconnected collective knowledge without a fixed perspective.
|
||||
- element: "issues/"
|
||||
owned_by:
|
||||
- model/task
|
||||
note: >-
|
||||
Mirror of an external ticket system to ease access; maps to the Task Model
|
||||
surface. The standard treats it as a mirror, not the system of record.
|
||||
- element: "history/"
|
||||
owned_by:
|
||||
- model/task
|
||||
- model/information-space
|
||||
note: >-
|
||||
Archive of finished/canceled material; yymmdd-prefixed; out of scope for
|
||||
daily working memory. Finished/canceled workplans move here (Task
|
||||
lifecycle) and archived knowledge persists (Information Space).
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Placement + extension candidates (WP-0009 discipline: explicit, reviewable,
|
||||
# no silent edits to existing standards/models).
|
||||
# ---------------------------------------------------------------------------
|
||||
candidates:
|
||||
- id: candidate/repository-layout-standard
|
||||
change_type: new-standard
|
||||
target: infospace/standards/repository-layout/
|
||||
summary: >-
|
||||
Author the InfoTechCanonRepositoryLayoutStandard defining the canonical
|
||||
directory set, yymmdd-prefix conventions (research/, history/), and the
|
||||
SCOPE->INTENT operating mode, referencing existing model concepts.
|
||||
disposition: approved-for-T03
|
||||
- id: candidate/canon-registration
|
||||
change_type: registration
|
||||
target:
|
||||
- canon.yaml (standards:)
|
||||
- infospace/infospace.yaml (disciplines:)
|
||||
- artifact index + retrieval generation
|
||||
- validation.py structural checks
|
||||
summary: Register the new standard so it is loaded, indexed, retrievable, and validated.
|
||||
disposition: approved-for-T03
|
||||
- id: candidate/conformance-levels
|
||||
change_type: standard-internal
|
||||
target: infospace/standards/repository-layout/
|
||||
summary: >-
|
||||
Define graded conformance (e.g. minimal / core / full) so adopting repos
|
||||
can be partial-conformant, honoring the source's recommendation posture.
|
||||
disposition: approved-for-T03
|
||||
- id: candidate/dogfood-canon-repo
|
||||
change_type: repo-reconciliation
|
||||
target: info-tech-canon repo layout
|
||||
summary: >-
|
||||
Reconcile this repo's own layout against the standard and record tensions
|
||||
(repo already uses spec/, wiki/, workplans/, seeds/; infospace uses the
|
||||
distinct kernel/models/standards layout). Decide dogfooding extent.
|
||||
disposition: deferred-to-T04
|
||||
- id: candidate/consumer-adoption-brief
|
||||
change_type: consumer-brief
|
||||
target: infospace/agent/consumer-briefs/ (or evaluations pack)
|
||||
summary: >-
|
||||
Adoption brief so the seven tracked domains can opt in from their own
|
||||
repos; per-repo adoption work stays in consumer repos (WP-0009 boundary).
|
||||
disposition: deferred-to-T05
|
||||
|
||||
disposition:
|
||||
outcome: extend_scope_via_new_standard
|
||||
recommended_next_step: Proceed to T03 — author and register the standard.
|
||||
no_silent_edits: true
|
||||
Reference in New Issue
Block a user