54d9540c08
Files changed: - .wikitool-kb.json - AGENTS.md - CHANGES.md - INSTALL-MCP.md - INSTALL.md - README.md - VERSION - instructions/capture-session.md - instructions/dev/issue-tracking.md - instructions/german-terminology.md - instructions/kb-profiles.md - instructions/migrate-corpus.md - instructions/migrations/5.0.0-confidence-removal.md - instructions/private-instance.md - instructions/setup-instance.md - instructions/wiki-lint/SKILL.md - instructions/wiki-manage/SKILL.md - instructions/wiki-query/SKILL.md - kb/CONTRACT.md - kb/CONVENTIONS.md - kb/CONVENTIONS.md.template - kb/concepts/architectures/Consolidation Tiers.md - kb/concepts/architectures/Context Isolation.md - kb/concepts/architectures/Cross-platform Agent Skills.md - kb/concepts/architectures/Episodic Memory.md - kb/concepts/architectures/Hybrid Search.md - kb/concepts/architectures/Implementation Spectrum.md - kb/concepts/architectures/Knowledge Graph.md - kb/concepts/architectures/LLM Wiki Pattern.md - kb/concepts/architectures/MCP-Leseserver.md - kb/concepts/architectures/Memory Lifecycle.md - kb/concepts/architectures/OKF Compatibility.md - kb/concepts/architectures/Optional Instance Context File.md - kb/concepts/architectures/Personalization Plane.md - kb/concepts/architectures/Procedural Memory.md - kb/concepts/architectures/RAG.md - kb/concepts/architectures/Scale Ceiling.md - kb/concepts/architectures/Semantic Memory.md - kb/concepts/architectures/Three-Layer Architecture.md - kb/concepts/architectures/Token Economics.md - kb/concepts/architectures/Working Memory.md - kb/concepts/decisions/Delete Rather Than Anonymize.md - kb/concepts/decisions/Denylist over Allowlist.md - kb/concepts/decisions/Diff-Reviewable Agent Edits.md - kb/concepts/decisions/Dual Licensing by File Plan.md - kb/concepts/decisions/Issue Label Scheme.md - kb/concepts/decisions/KB Stack Versioning.md - kb/concepts/decisions/Structural Enforcement over Documented Rule.md - kb/concepts/patterns/Audit Trail.md - kb/concepts/patterns/BM25.md - kb/concepts/patterns/Command Round-Trip Integrity.md - kb/concepts/patterns/Confidence Scoring.md - kb/concepts/patterns/Contradiction Resolution.md - kb/concepts/patterns/Entity Extraction.md - kb/concepts/patterns/Filter on Ingest.md - kb/concepts/patterns/Forgetting.md - kb/concepts/patterns/Graph Traversal.md - kb/concepts/patterns/Mesh Sync.md - kb/concepts/patterns/Quality Scoring.md - kb/concepts/patterns/Reciprocal Rank Fusion.md - kb/concepts/patterns/Self-Healing.md - kb/concepts/patterns/Shared vs Private.md - kb/concepts/patterns/Typed Relationships.md - kb/concepts/patterns/Vector Search.md - kb/concepts/patterns/Work Coordination.md - kb/concepts/problems/Ambient Environment Dependency.md - kb/concepts/problems/Detect-Repair Asymmetry.md - kb/concepts/problems/Green Suite Blind Spot.md - kb/concepts/problems/Naming Convention Conflict.md - kb/concepts/problems/Write-Once Frontmatter Fields.md - kb/concepts/protocols/CPPC.md - kb/concepts/protocols/Modbus.md - kb/concepts/protocols/SSD TRIM.md - kb/concepts/workflows/Anti-Cramming Heuristic.md - kb/concepts/workflows/Bulk Operations.md - kb/concepts/workflows/CI Integration.md - kb/concepts/workflows/Checkpoint Audit.md - kb/concepts/workflows/Claude Code Auto Mode.md - kb/concepts/workflows/Content Quality Control.md - kb/concepts/workflows/Crystallization.md - kb/concepts/workflows/Event-Driven Automation.md - kb/concepts/workflows/Hooks.md - kb/concepts/workflows/Index Scaling.md - kb/concepts/workflows/Iteration and Cost Limits.md - kb/concepts/workflows/KB Migration.md - kb/concepts/workflows/Knowledge Compounding.md - kb/concepts/workflows/Lint Workflow.md - kb/concepts/workflows/Mass-Update Gate.md - kb/concepts/workflows/Multi-Agent Collaboration.md - kb/concepts/workflows/Privacy and Governance.md - kb/concepts/workflows/Publish-Remote Gate.md - kb/concepts/workflows/Quality and Self-Correction.md - kb/concepts/workflows/Semantic Lint Automation.md - kb/concepts/workflows/Session Orientation.md - kb/concepts/workflows/Split Merge Reclassify.md - kb/concepts/workflows/Split Threshold.md - kb/concepts/workflows/Stub Threshold.md - kb/concepts/workflows/Supersession.md - kb/concepts/workflows/User Management.md - kb/concepts/workflows/Workflow Extraction.md - kb/concepts/workflows/Workflow Orchestration.md - kb/entities/people/Andrej Karpathy.md - kb/entities/people/E3DC GmbH.md - kb/entities/people/Rohit Gupta.md - kb/entities/people/Vannevar Bush.md - kb/entities/projects/BCDModule.md - kb/entities/projects/Chemenu.md - kb/entities/projects/andybalholm-edl.md - kb/entities/projects/goresponsiveness.md - kb/entities/projects/ha-core.md - kb/entities/projects/hacs-e3dc.md - kb/entities/projects/hacs-integration-blueprint.md - kb/entities/projects/llm-wiki-skills.md - kb/entities/projects/plugnburn-edl.md - kb/entities/projects/wiki-skills-vanillaflava.md - kb/entities/projects/wiki-skills.md - kb/entities/systems/AGENTS.md.md - kb/entities/systems/CLAUDE.md.md - kb/entities/systems/E3DC.md - kb/entities/systems/ENVIRONMENT.md.md - kb/entities/systems/Memex.md - kb/entities/systems/Tolkien Gateway.md - kb/entities/technologies/Arch Linux.md - kb/entities/technologies/Disk Encryption.md - kb/entities/technologies/Docker.md - kb/entities/technologies/GRUB.md - kb/entities/technologies/Gitea Actions.md - kb/entities/technologies/Gitea.md - kb/entities/technologies/Go.md - kb/entities/technologies/Home Assistant.md - kb/entities/technologies/Kernel PM Governors.md - kb/entities/technologies/LVM.md - kb/entities/technologies/Linux Kernel.md - kb/entities/technologies/MQTT.md - kb/entities/technologies/OPC UA.md - kb/entities/technologies/Python.md - kb/entities/technologies/Rust.md - kb/entities/technologies/Wine GE.md - kb/entities/technologies/Wine-Staging.md - kb/entities/technologies/acpi-cpufreq.md - kb/entities/technologies/amd-pstate.md - kb/entities/technologies/iii Engine.md - kb/entities/tools/AUR.md - kb/entities/tools/Act Runner.md - kb/entities/tools/Agent Memory.md - kb/entities/tools/Aura.md - kb/entities/tools/Bottles.md - kb/entities/tools/ChatGPT.md - kb/entities/tools/Claude Code.md - kb/entities/tools/Codex CLI.md - kb/entities/tools/Dataview.md - kb/entities/tools/GPG.md - kb/entities/tools/GitHub Copilot.md - kb/entities/tools/Gitea MCP Server.md - kb/entities/tools/Lutris.md - kb/entities/tools/Marp.md - kb/entities/tools/Mistral Vibe.md - kb/entities/tools/NotebookLM.md - kb/entities/tools/Obsidian Web Clipper.md - kb/entities/tools/Obsidian.md - kb/entities/tools/OpenAI Codex.md - kb/entities/tools/OpenCode.md - kb/entities/tools/Pi.md - kb/entities/tools/Proton.md - kb/entities/tools/Steam.md - kb/entities/tools/Wine.md - kb/entities/tools/awesome-llm-wiki.md - kb/entities/tools/farzaa gist.md - kb/entities/tools/gdeploy.md - kb/entities/tools/makepkg.md - kb/entities/tools/pascalandy schema.md - kb/entities/tools/qmd.md - kb/entities/tools/wikitool.md - kb/index.md - kb/log.md - raw/CONTRACT.md - tools/CONTRACT.md - tools/README.md - tools/chemenu/api.py - tools/chemenu/cli.py - tools/chemenu/commands/confidence_decay.py - tools/chemenu/commands/docs_verify.py - tools/chemenu/commands/doctor.py - tools/chemenu/commands/index_build.py - tools/chemenu/commands/new_page.py - tools/chemenu/commands/search.py - tools/chemenu/commands/touch.py - tools/chemenu/commands/version_cmd.py - tools/chemenu/conventions.py - tools/chemenu/corpus_diff.py - tools/chemenu/frontmatter_io.py - tools/chemenu/lint_core.py - tools/chemenu/mcp/server.py - tools/chemenu/page.py - tools/chemenu/search/base.py - tools/chemenu/search/filters.py - tools/chemenu/search/ripgrep.py - tools/chemenu/search/service.py - tools/chemenu/search/types.py - tools/chemenu/tests/conftest.py - tools/chemenu/tests/test_api.py - tools/chemenu/tests/test_confidence_decay.py - tools/chemenu/tests/test_corpus_diff.py - tools/chemenu/tests/test_docs_verify.py - tools/chemenu/tests/test_frontmatter_io.py - tools/chemenu/tests/test_index_build.py - tools/chemenu/tests/test_kb_scan.py - tools/chemenu/tests/test_lint.py - tools/chemenu/tests/test_mcp_server.py - tools/chemenu/tests/test_new_page.py - tools/chemenu/tests/test_page_ops.py - tools/chemenu/tests/test_provenance.py - tools/chemenu/tests/test_raw_cmd.py - tools/chemenu/tests/test_search.py - tools/chemenu/tests/test_touch.py - tools/chemenu/tests/test_type_resolver.py - tools/chemenu/tests/test_version_cmd.py - tools/chemenu/tests/test_xref.py - tools/chemenu/version.py - types/concept.md - types/concept.schema.yaml - types/entity.md - types/entity.schema.yaml - types/instruction.md - types/type-spec.md
234 lines
12 KiB
Markdown
234 lines
12 KiB
Markdown
---
|
|
type: types/instruction.md
|
|
name: kb-profiles
|
|
description: Ready-made answers for kb/CONVENTIONS.md and each COLLECTION.md - the proven collection contracts and language profiles this stack has shipped, offered as a palette to adopt or adapt, never as a binding source.
|
|
manual: true
|
|
---
|
|
# Pick a profile for a collection or for this instance's conventions
|
|
|
|
**This page is a palette, not an enum.** Each `kb/<name>/COLLECTION.md` stays authoritative for
|
|
its own collection and `kb/CONVENTIONS.md` for the instance as a whole; an entry here is a
|
|
proven starting point, nothing more. Adopting one means *copying its text into* that file - not
|
|
pointing at this page and inheriting whatever it says later. Nothing in the stack reads this
|
|
document, and `profile:` in a contract's frontmatter records where the text came from, not where
|
|
it lives.
|
|
|
|
That direction is deliberate and it is the opposite of how this repo used to work. Language,
|
|
tone, naming and the relationship vocabulary sat in `kb/CONTRACT.md`, a file `dist export` ships
|
|
verbatim - so every instance that wanted something else edited a stack file, and an upstream
|
|
merge handed the stack's answer back. What binds is now the instance's; what ships is this
|
|
catalogue, and it binds nothing.
|
|
|
|
<!-- wikitool:toc -->
|
|
## Contents
|
|
|
|
- [When to run](#when-to-run)
|
|
- [Steps](#steps)
|
|
- [Language profiles](#language-profiles)
|
|
- [`german`](#german)
|
|
- [`english`](#english)
|
|
- [Writing a third one](#writing-a-third-one)
|
|
- [Collection profiles](#collection-profiles)
|
|
- [`entities`](#entities)
|
|
- [`concepts`](#concepts)
|
|
- [`sources`](#sources)
|
|
- [`comparisons`](#comparisons)
|
|
- [Decision points](#decision-points)
|
|
- [Scope](#scope)
|
|
<!-- /wikitool:toc -->
|
|
|
|
## When to run
|
|
|
|
- Setting up a new instance: the KB-language step of
|
|
[setup-instance.md](setup-instance.md) sends you here to fill `kb/CONVENTIONS.md`.
|
|
- Adding a collection to an existing instance, and wanting a contract that already works rather
|
|
than a blank one.
|
|
- Rewriting an existing `COLLECTION.md` or `kb/CONVENTIONS.md` and wanting to see what the
|
|
alternatives were.
|
|
|
|
Not for changing what the *stack* enforces. That is [kb/CONTRACT.md](../kb/CONTRACT.md), and it
|
|
is not a profile.
|
|
|
|
## Steps
|
|
|
|
1. **Decide what you are filling.** Two different files, and they are not interchangeable:
|
|
|
|
| File | Holds | Profiles below |
|
|
|---|---|---|
|
|
| `kb/CONVENTIONS.md` | Language, section headings, naming forms, tone, relationship labels, the hedging rule - once per instance | [Language profiles](#language-profiles) |
|
|
| `kb/<name>/COLLECTION.md` | What one collection holds, its quality goal, its local linking and naming rules | [Collection profiles](#collection-profiles) |
|
|
|
|
2. **Copy the entry's text into the file**, then edit it until it is true of this instance.
|
|
A profile you adopted and then changed is still that profile's `profile:` value - the field
|
|
records the starting point, not a promise of fidelity.
|
|
|
|
3. **Record it.** `profile: <name>` in the file's frontmatter, or `profile: none` for a
|
|
collection written from scratch. `wikitool docs verify` checks the field is there; it does
|
|
not check the value against this page, because a collection an instance invented has no
|
|
entry here to name.
|
|
|
|
4. **Set `required_by_stack:` on a collection - and set it correctly.** This one is *not* a
|
|
choice: it says whether `wikitool` resolves against the collection by name, and
|
|
`docs verify` checks it against the stack's own list. `sources` is `true`, everything else
|
|
is `false`. See [kb/CONTRACT.md § Collections](../kb/CONTRACT.md#collections).
|
|
|
|
## Language profiles
|
|
|
|
A language profile answers all of `kb/CONVENTIONS.md` at once. There is one today, because one
|
|
is what this repo has actually run.
|
|
|
|
### `german`
|
|
|
|
The profile this repo's own instance uses, and the reason this catalogue exists: it was the
|
|
stack's hardcoded behaviour until the conventions file existed.
|
|
|
|
| Decides | Value |
|
|
|---|---|
|
|
| `language:` | `de` |
|
|
| `sections:` | `Beziehungen` / `Siehe auch` / `Fußnoten` |
|
|
| Naming | Human-readable titles with spaces; singular for entities; a decision named like any other concept, no `adr-NNN-` prefix; `X vs Y` for comparisons |
|
|
| Tone | Wikipedia register, with a German buzzword and filler list |
|
|
| Relationship labels | `hängt ab von` · `verwendet` · `implementiert` · `erweitert` · `ersetzt` · `steht in Konflikt mit` · `benötigt` · `erzeugt` · `konsumiert` · `besitzt` · `pflegt` · `läuft auf` · `verwandt mit` |
|
|
| Hedging | By source standing, not a score: `provenance: general` with no `sources:` says "im Allgemeinen"/"üblicherweise"; a claim rests on its weakest cited source's `authority` (`normative` vs. `opinion`); disagreement is named in prose ("möglicherweise", "laut X, aber Y widerspricht") |
|
|
| Terminology | [german-terminology.md](german-terminology.md) - which English terms stay English, and which have a settled German form |
|
|
|
|
**The full text to copy** is this repo's own [kb/CONVENTIONS.md](../kb/CONVENTIONS.md). An
|
|
instance adopting it takes that file, not this table; the table is what the profile *decides*,
|
|
so you can tell at a glance whether it is the one you want.
|
|
|
|
Adopting it also means keeping `german-terminology.md`. An instance on any other language
|
|
deletes or replaces that file - it is the profile's lookup material, not the stack's.
|
|
|
|
### `english`
|
|
|
|
What `kb/CONVENTIONS.md.template` ships as its default, so "adopt `english`" means "fill in the
|
|
template and change nothing structural". `sections:` are `Relationships` / `See Also` /
|
|
`Footnotes`, which are also the names this stack wrote before it had a conventions file - so a
|
|
corpus that predates the split needs no translation pass to adopt this profile.
|
|
|
|
There is no worked text for the rest of it. The template's placeholders are the questions;
|
|
`german` above is what a filled answer looks like.
|
|
|
|
### Writing a third one
|
|
|
|
A language profile is not a translation of `german`. Two of its sections are judgment about a
|
|
language rather than vocabulary in it - which foreign technical terms stay untranslated, and how
|
|
to phrase hedged and disagreeing claims - and those are exactly the two that read as awkward when
|
|
translated mechanically. Write them, do not convert them.
|
|
|
|
The one part that is mechanical: `section_aliases:`. Whatever the corpus used before goes in
|
|
that list, and the pages then migrate one at a time instead of all at once.
|
|
|
|
## Collection profiles
|
|
|
|
The four collections this repo runs. Each is a whole `COLLECTION.md`, and **the text to copy is
|
|
the file itself** - `dist export` ships each one as `kb/<name>/COLLECTION.md.template`, which a
|
|
new instance adopts by renaming. What follows is what each decides, so you can tell whether you
|
|
want it.
|
|
|
|
### `entities`
|
|
|
|
Concrete, pointable things: projects, deployed systems, tools, technologies, people.
|
|
|
|
- **Quality goal:** pointability plus currency - what the thing is, where it actually is, and
|
|
whether that is still true.
|
|
- **Areas** driven by the `entity_type:` field: `projects/`, `systems/`, `tools/`,
|
|
`technologies/`, `people/`. Areas, not collections - they inherit the contract and carry no
|
|
`COLLECTION.md`.
|
|
- **Per-area emphasis** spelled out, so a system page is not written like a technology page.
|
|
- `required_by_stack: false`.
|
|
|
|
Take it when the wiki is about things that exist. Adapt the area list first: it is the part most
|
|
likely to be wrong for another domain.
|
|
|
|
### `concepts`
|
|
|
|
Ideas rather than things: architectures, patterns, protocols, workflows, recurring problems,
|
|
and the decisions taken about them.
|
|
|
|
- **Quality goal:** explanatory sufficiency - the page answers *why it is done this way* without
|
|
the reader opening the entity pages that use it.
|
|
- Carries the **ADR shape**: context, decision, consequences, status, and the rule that a
|
|
superseded decision is never rewritten.
|
|
- Routes head-to-head arguments out to `comparisons/` rather than hosting them.
|
|
- `required_by_stack: false`.
|
|
|
|
Take it whenever `entities` is taken - the split between the two is what keeps either from
|
|
becoming an essay.
|
|
|
|
### `sources`
|
|
|
|
One page per ingested source, carrying the `raw_files:` provenance every citation resolves
|
|
against.
|
|
|
|
- **Quality goal:** faithful compression - what *this source* said, not what was concluded from
|
|
it. A source page improved beyond its source is no longer evidence.
|
|
- Titles carry the `Source - ` prefix, applied by `wikitool new source`.
|
|
- `required_by_stack: **true**`. `sources coverage`, `[^cite-id]` resolution and
|
|
`kb/provenance.md` resolve against the name `sources`.
|
|
|
|
Not optional in the way the others are. An instance may rewrite its authoring rules and may not
|
|
rename or drop it.
|
|
|
|
**`source_type` is a palette too, and the part most likely to be wrong for another domain -
|
|
adapt its value list first**, the same way `entities`' area list is called out above. This
|
|
repo's own list (`transcript, analysis, article, document, notes, tracker, unclassified`)
|
|
describes *what a private-projects instance ingests*; it says nothing about what a source is in
|
|
a different domain. Two worked lists, to show how little the values carry over:
|
|
|
|
| Instance | Plausible `source_type` values |
|
|
|---|---|
|
|
| Handball club and federation | `satzung` (bylaws), `protokoll` (minutes), `korrespondenz`, `spielbericht` (match report), `verbandsmitteilung` |
|
|
| Tabletop game master | `regelwerk` (rulebook), `abenteuermodul` (module), `sessionlog`, `handout`, `weltenbau` (worldbuilding) |
|
|
|
|
Adopting one means copying the value list into `types/source.schema.yaml`'s enum and giving each
|
|
value a `layout:` line in `types/source.md` - the same "copy the text in, do not point at this
|
|
page" rule as every other profile here. Keep the visible catch-all value (`unclassified` above)
|
|
in whatever list is adopted: a subtype field without one silently reintroduces the old
|
|
`default:`-driven collection point this stack removed, the moment nobody names an edge case.
|
|
Growing the list later, or draining the catch-all, is
|
|
[evolve-subtypes.md](evolve-subtypes.md).
|
|
|
|
**Not up for choice: `fidelity` and `authority`.** Unlike `source_type`, these two capture
|
|
fields are stack vocabulary - `types/source.md`'s `capture_fields:` - because they held the same
|
|
few values across every domain this catalogue tried, where `source_type` did not. An instance
|
|
adapts the *value list* above; it does not touch `fidelity`'s or `authority`'s enums.
|
|
|
|
### `comparisons`
|
|
|
|
Structured head-to-head evaluations of two or more things that already have pages.
|
|
|
|
- **Quality goal:** decidability - named, checkable dimensions and a stated trade-off, so a
|
|
reader with a concrete situation can choose.
|
|
- Every subject must already have a page; a comparison is a view over existing knowledge.
|
|
- **Exempt from the orphan check** - comparisons are reached through the catalog, not through
|
|
inbound prose links.
|
|
- `required_by_stack: false`.
|
|
|
|
Skip it in a wiki that records rather than decides. It is the one of the four that is genuinely
|
|
optional.
|
|
|
|
## Decision points
|
|
|
|
- **A profile is almost right?** Copy and edit. There is no partial adoption and no override
|
|
file - the copy *is* the mechanism, and `profile:` still records where it started.
|
|
- **Two collections want the same profile?** Fine. `profile:` is not unique, and two
|
|
collections holding different subject matter under the same authoring rules is an ordinary
|
|
outcome.
|
|
- **Changing `sections:` after pages exist?** That is a corpus migration, not an edit. Put the
|
|
old names in `section_aliases:` first, then translate page by page - the tool keeps finding
|
|
the old headings for as long as the alias stands. See
|
|
[migrate-corpus.md](migrate-corpus.md).
|
|
- **Tempted to make this page binding** - to have `COLLECTION.md` say `profile: entities` and
|
|
nothing else? Do not. That is the arrangement this split was written to end: the instance
|
|
would be bound by a file the stack ships and upgrades, which is how an upstream merge changes
|
|
an instance's authoring rules without anyone deciding to.
|
|
|
|
## Scope
|
|
|
|
Covers what an instance authors under `kb/`. It says nothing about what the stack enforces
|
|
([kb/CONTRACT.md](../kb/CONTRACT.md)), what a page structurally is
|
|
([types/type-spec.md](../types/type-spec.md)), or how a command behaves
|
|
([tools/CONTRACT.md](../tools/CONTRACT.md)). None of those are profiles, and none of them are
|
|
the instance's to change.
|