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