generated from coulomb/repo-seed
92 lines
5.9 KiB
YAML
92 lines
5.9 KiB
YAML
id: comparison/repo-scoping/extension-candidates
|
|
title: Repo Scoping Canon Extension Candidates
|
|
status: candidate
|
|
consumer: repo-scoping
|
|
comparison_report: comparison/repo-scoping/report
|
|
candidate_set_status: review-required
|
|
candidates:
|
|
- id: extension/repository-intent-statement
|
|
title: RepositoryIntentStatement
|
|
proposed_owner: model/purpose-demand-extension
|
|
change_type: new-concept
|
|
problem: Intent is currently generic; repo-scoping needs a design-time repository utility statement that can seed but not prove current scope.
|
|
proposed_definition: A design-time statement of expected repository utility, distinct from current scope and consumer purpose.
|
|
review_question: Should this be a specialization of Intent or a repository-scoping profile concept?
|
|
- id: extension/repository-scope-profile
|
|
title: RepositoryScopeProfile
|
|
proposed_owner: model/information-space
|
|
change_type: new-profile
|
|
problem: Generic Scope does not capture source-linked current-state repository utility and SCOPE.md generation ownership.
|
|
proposed_definition: A current-state, source-linked profile describing what a repository is useful for, when it is relevant, and which approved claims support it.
|
|
review_question: Should this be a profile of Information Space, Governance, or a cross-model application profile?
|
|
- id: extension/characteristic-claim
|
|
title: CharacteristicClaim
|
|
proposed_owner: model/governance
|
|
change_type: new-concept
|
|
problem: Repo-scoping uses Scope, Ability, Capability, and Feature as reviewable claims rather than merely descriptive tags.
|
|
proposed_definition: An interpreted, reviewable claim about a repository at a declared abstraction level with confidence, evidence, provenance, and review status.
|
|
review_question: Should Ability, Capability, and Feature be levels of CharacteristicClaim or separate profile concepts?
|
|
- id: extension/evidence-link
|
|
title: EvidenceLink
|
|
proposed_owner: model/information-space
|
|
change_type: new-concept
|
|
problem: Governance Evidence is too coarse for support links that target observed facts, content chunks, files, and lower-level characteristics.
|
|
proposed_definition: A typed support relation from a claim to a source observation, content chunk, artifact, or lower-level claim.
|
|
review_question: Should EvidenceLink live in Information Space while Evidence remains Governance/Observability owned?
|
|
- id: extension/source-observation
|
|
title: SourceObservation
|
|
proposed_owner: model/information-space
|
|
change_type: new-concept
|
|
problem: Observed facts are deterministic scanner outputs and should not become evidence or truth claims without interpretation.
|
|
proposed_definition: A source-linked observation extracted from repository content, metadata, or execution results, before review or promotion.
|
|
review_question: How should SourceObservation relate to Observability signals and Information Space chunks?
|
|
- id: extension/source-role
|
|
title: SourceRole
|
|
proposed_owner: standard/tagging
|
|
change_type: new-taxonomy
|
|
problem: Repo-scoping needs stable labels such as intent_summary, derived_scope, product_documentation, implementation_source, dependency_declaration, and agent_guidance.
|
|
proposed_definition: A tag or classification describing the role a source artifact plays in repository utility evaluation.
|
|
review_question: Should SourceRole be a tagging profile or part of Information Space provenance?
|
|
- id: extension/utility-relationship
|
|
title: UtilityRelationship
|
|
proposed_owner: model/governance
|
|
change_type: new-taxonomy
|
|
problem: Provider, dependency, tooling, mention, owned, facade, and adapter relationships decide whether evidence can become a provided capability.
|
|
proposed_definition: A classification of how source evidence relates to claimed repository utility.
|
|
review_question: Should these labels become governance decision criteria for approving capability claims?
|
|
- id: extension/scope-freshness
|
|
title: ScopeFreshness
|
|
proposed_owner: model/task
|
|
change_type: new-concept
|
|
problem: Repo-scoping tracks stale downstream claims when observed facts change, but the canon lacks freshness semantics for repository scope.
|
|
proposed_definition: A state describing whether a scope claim is current, stale, needs recalculation, needs review, superseded, or rejected.
|
|
review_question: Should freshness be task state, governance review state, or a profile-specific quality signal?
|
|
- id: extension/propagation-impact
|
|
title: PropagationImpact
|
|
proposed_owner: model/task
|
|
change_type: new-concept
|
|
problem: Repo-scoping measures propagation breadth and depth from changed facts to approved scope claims.
|
|
proposed_definition: A traceable impact result showing which claims may be stale because upstream evidence changed.
|
|
review_question: Can this generalize to other evidence-driven canon consumers?
|
|
- id: extension/scope-md-interface
|
|
title: ScopeMdInterface
|
|
proposed_owner: model/information-space
|
|
change_type: new-interface-profile
|
|
problem: SCOPE.md has a stable section contract and machine-readable capability blocks that should be reusable.
|
|
proposed_definition: A markdown interface profile for repository orientation, generated sections, curator-owned sections, and provided capability blocks.
|
|
review_question: Should this become an interface-card specialization?
|
|
disposition:
|
|
recommended_next_step: Create a dedicated Repository Scope Profile workplan after repo-scoping consumer adoption begins.
|
|
immediate_standard_changes: []
|
|
hold_for_review:
|
|
- extension/repository-intent-statement
|
|
- extension/repository-scope-profile
|
|
- extension/characteristic-claim
|
|
- extension/evidence-link
|
|
- extension/source-observation
|
|
- extension/source-role
|
|
- extension/utility-relationship
|
|
- extension/scope-freshness
|
|
- extension/propagation-impact
|
|
- extension/scope-md-interface
|