tegwick
27b7e3f08a
Insert a 'tooling' category between project and product (reusable internal tooling/infrastructure: libraries, CLIs, services, ops components used across the ecosystem rather than offered to external customers). Update §5 definition, §11 decision procedure, §16 agent prompt, the machine-readable allowed-values, and the CUST-WP-0050 T02 progress note. Nine custodian tooling repos reclassified to it; the-custodian and inter-hub remain research. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
113 lines
2.5 KiB
YAML
113 lines
2.5 KiB
YAML
# Machine-readable allowed-values for the Repo Classification Standard.
|
|
#
|
|
# Single source of truth for the standard's controlled vocabularies, derived
|
|
# from canon/standards/repo-classification-standard_v1.0.md. Consumed by:
|
|
# - the per-repo .repo-classification.yaml linter (tools/validate_repo_classification.py)
|
|
# - the State Hub registration validator (CUST-WP-0050 T04)
|
|
#
|
|
# When the standard's vocabularies change, update this file and bump `version`
|
|
# to match the standard version. CUST-WP-0050 T01.
|
|
|
|
standard: "Repo Classification Standard"
|
|
version: "1.0"
|
|
canon_id: "canon-repo-classification"
|
|
|
|
# category — exactly 1 required (§5)
|
|
categories:
|
|
- experimental
|
|
- research
|
|
- project
|
|
- tooling
|
|
- product
|
|
- business
|
|
|
|
# domain / secondary_domains — primary exactly 1; secondaries 0..n (§6)
|
|
domains:
|
|
- infotech
|
|
- financials
|
|
- communication
|
|
- consumer
|
|
- health
|
|
- industrials
|
|
- energy
|
|
- utilities
|
|
- materials
|
|
- realestate
|
|
- crypto
|
|
- agents
|
|
- space
|
|
- government
|
|
|
|
# business_stake — 0..n; 2..6 recommended (§8)
|
|
business_stake:
|
|
- execution
|
|
- intelligence
|
|
- finance
|
|
- legal
|
|
- sales
|
|
- experience
|
|
- technology
|
|
- operations
|
|
- product
|
|
- people
|
|
- procurement
|
|
- sustainability
|
|
- automation
|
|
|
|
# business_mechanics — 0..n, optional (§9)
|
|
business_mechanics:
|
|
- intention
|
|
- control
|
|
- coordination
|
|
- operation
|
|
- adaptation
|
|
|
|
# capability_tags are intentionally OPEN-ENDED (§7): lowercase kebab-case, not
|
|
# restricted to this set. The families below are the standard's recommended
|
|
# canonical tags — used to warn on likely synonyms/typos, never to reject.
|
|
capability_families:
|
|
identity_and_access:
|
|
- identity
|
|
- authentication
|
|
- authorization
|
|
- access-control
|
|
- user-management
|
|
- tenancy
|
|
knowledge_and_evidence:
|
|
- knowledge
|
|
- citations
|
|
- evidence
|
|
- source-management
|
|
- traceability
|
|
- documentation
|
|
platform_and_operations:
|
|
- platform
|
|
- deployment
|
|
- operations
|
|
- observability
|
|
- feature-control
|
|
- configuration
|
|
- orchestration
|
|
market_and_coordination:
|
|
- marketplace
|
|
- pricing
|
|
- reputation
|
|
- challenges
|
|
- bounties
|
|
- collaboration
|
|
- coordination
|
|
governance_and_control:
|
|
- governance
|
|
- policy
|
|
- compliance
|
|
- risk
|
|
- audit
|
|
- control
|
|
|
|
# Validation guidance (advisory bounds the linter applies as warnings)
|
|
guidance:
|
|
secondary_domains_max: 3
|
|
business_stake_recommended_min: 2
|
|
business_stake_recommended_max: 6
|
|
capability_tag_pattern: "^[a-z0-9]+(-[a-z0-9]+)*$"
|