Curate architecture knowledge
Maintain reusable architecture knowledge without turning volatile product
claims into timeless rules.
Load the contracts
Read:
../../../resources/references/knowledge-contract.md;../../../resources/knowledge/manifest.yaml;../../../resources/schemas/knowledge-entry.schema.json;../../../resources/schemas/knowledge-manifest.schema.json;../../../resources/schemas/rule-pack.schema.json;../../../resources/schemas/evidence-provider.schema.json;../../../resources/schemas/evidence-provider-config.schema.json;../../../resources/schemas/evidence-run.schema.json;../../../resources/references/evidence-provider-contract.md;- only the Markdown entries, Rule Packs, or provider contracts affected by the
request.
Classify the change
Classify knowledge before editing:
- stable: quality concepts, architecture styles, patterns, and tradeoffs;
- slow-changing: framework capabilities, operating models, and lock-in;
- fast-changing: versions, support status, compatibility, security advisories,
pricing, and product lifecycle.
Keep stable knowledge in Markdown/frontmatter entries. Record official-source
URLs and a review window for slow-changing knowledge. Mark technology profiles
as dynamic and verify fast-changing facts from current official sources at use
time; do not freeze them into a Skill.
Curation workflow
- Define the decision changed by the proposed entry.
- Use standards, official documentation, or maintainer documentation as
sources. Use research only for claims absent from authoritative sources.
- Follow
../../../docs/knowledge-authoring.md and record all fourteen
required body sections plus canonical ID, version, kind, domains, triggers,
qualities, relationships, sources, source policy, and freshness.
- Describe what a style, pattern, or technology does not solve.
- Keep technology and architecture style separate.
- Reject entries that merely repeat a product name, popularity claim, or
unbounded best practice.
- Deduplicate by decision semantics. Preserve different entries when
similarly named mechanisms have different ownership or failure behavior.
- Update associated decision rules, reference architecture, migration guide,
provider, tests, and changelog when behavior changes.
Do not change a Rule Pack solely because a tool can detect a metric. A rule
must protect one invariant at an owning boundary and specify evidence
requirements.
Validate
Run:
python3 ../../../resources/scripts/validate_knowledge.py
python3 ../../../scripts/validate_repository.py
Report added, changed, removed, or stale entries and their official sources.
Do not audit a repository, select its target architecture, or modify product
code.
1---2name: architecture-knowledge-curator3description: Maintains the plugin's architecture quality models, styles, patterns, technology profiles, reference architectures, migration guides, domain guidance, decision rules, machine rule packs, and evidence-provider registry. Use when adding or refreshing architecture knowledge, checking official-source freshness, reviewing framework capability claims, resolving duplicate or contradictory entries, or preparing a release whose decision knowledge may be stale. Does not audit a product or choose a product architecture.4---56# Curate architecture knowledge78Maintain reusable architecture knowledge without turning volatile product9claims into timeless rules.1011## Load the contracts1213Read:1415- `../../../resources/references/knowledge-contract.md`;16- `../../../resources/knowledge/manifest.yaml`;17- `../../../resources/schemas/knowledge-entry.schema.json`;18- `../../../resources/schemas/knowledge-manifest.schema.json`;19- `../../../resources/schemas/rule-pack.schema.json`;20- `../../../resources/schemas/evidence-provider.schema.json`;21- `../../../resources/schemas/evidence-provider-config.schema.json`;22- `../../../resources/schemas/evidence-run.schema.json`;23- `../../../resources/references/evidence-provider-contract.md`;24- only the Markdown entries, Rule Packs, or provider contracts affected by the25 request.2627## Classify the change2829Classify knowledge before editing:3031- stable: quality concepts, architecture styles, patterns, and tradeoffs;32- slow-changing: framework capabilities, operating models, and lock-in;33- fast-changing: versions, support status, compatibility, security advisories,34 pricing, and product lifecycle.3536Keep stable knowledge in Markdown/frontmatter entries. Record official-source37URLs and a review window for slow-changing knowledge. Mark technology profiles38as dynamic and verify fast-changing facts from current official sources at use39time; do not freeze them into a Skill.4041## Curation workflow42431. Define the decision changed by the proposed entry.442. Use standards, official documentation, or maintainer documentation as45 sources. Use research only for claims absent from authoritative sources.463. Follow `../../../docs/knowledge-authoring.md` and record all fourteen47 required body sections plus canonical ID, version, kind, domains, triggers,48 qualities, relationships, sources, source policy, and freshness.494. Describe what a style, pattern, or technology does not solve.505. Keep technology and architecture style separate.516. Reject entries that merely repeat a product name, popularity claim, or52 unbounded best practice.537. Deduplicate by decision semantics. Preserve different entries when54 similarly named mechanisms have different ownership or failure behavior.558. Update associated decision rules, reference architecture, migration guide,56 provider, tests, and changelog when behavior changes.5758Do not change a Rule Pack solely because a tool can detect a metric. A rule59must protect one invariant at an owning boundary and specify evidence60requirements.6162## Validate6364Run:6566```bash67python3 ../../../resources/scripts/validate_knowledge.py68python3 ../../../scripts/validate_repository.py69```7071Report added, changed, removed, or stale entries and their official sources.72Do not audit a repository, select its target architecture, or modify product73code.
qingye-lab