From eabd4ad23ed138a720c746f8918b62fbfabf3b75 Mon Sep 17 00:00:00 2001 From: codex Date: Sat, 5 Sep 2026 22:08:58 +0200 Subject: [PATCH] Open CUST-WP-0069: add the publication category to the classification standard MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Classifying hall-of-helix had no honest answer. A curated, permanent corpus of authored records fits none of the six categories, and the fallback — project — is the only non-durable one, implying eventual retirement of a record meant to be permanent. With no classification file at all, resolve_flavor currently falls through to flavor=tooling, so the repo is misclassified silently. publication joins DURABLE_FLAVORS: repos whose purpose is to publish and keep a body of authored content, where the corpus itself is the deliverable. Population is one today — a scan of all 131 registered repos found no other true publication — which argues for adding it once and carefully rather than misfiling a permanent record as transient work. Version 1.1, not 2.0: the addition is purely additive, no existing classification becomes invalid, and neither validator enforces a version match, so the 125 repo files declaring 1.0 keep validating. T01 clarifies §17, which currently reads any allowed-value change as major. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01SQ6oF1DtVDKcD1FCpvRVLx --- .../CUST-WP-0069-publication-repo-category.md | 126 ++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 workplans/CUST-WP-0069-publication-repo-category.md diff --git a/workplans/CUST-WP-0069-publication-repo-category.md b/workplans/CUST-WP-0069-publication-repo-category.md new file mode 100644 index 0000000..b74abeb --- /dev/null +++ b/workplans/CUST-WP-0069-publication-repo-category.md @@ -0,0 +1,126 @@ +--- +id: CUST-WP-0069 +type: workplan +title: "Add the publication category to the Repo Classification Standard" +domain: infotech +repo: the-custodian +status: active +owner: claude-code +topic_slug: custodian +priority: medium +created: "2026-09-05" +updated: "2026-09-05" +quality_dor: DoR-Ok +quality_dor_at: "2026-09-05" +quality_dor_by: claude-code +quality_dor_note: "Classifying hall-of-helix exposed a real gap: a published corpus of authored records fits none of the six categories, and the fallback (project) is the only non-durable one, implying eventual retirement of a permanent record. The change is additive and no existing classification becomes invalid, so the enforcement points are known and bounded." +related: + - HOH-WP-0001 +--- + +# Add the publication category to the Repo Classification Standard + +Classifying `hall-of-helix` had no honest answer. It is a curated, permanent +corpus of authored first-person records — a record of who engaged on the Helix +Forge platform. None of the six categories fit: + +- `research` is knowledge work answering "what do we need to understand?"; +- `tooling`, `product`, `business`, `experimental` are plainly not it; +- `project` is the only **non-durable** category (`DURABLE_FLAVORS` in + `repo-manager/standards.py` contains the other five), reserved for bounded + work "not yet productized" that later resolves or retires. A hall of + remembrance does not retire. + +Today `hall-of-helix` has no classification file at all, so `resolve_flavor` +falls through to `flavor = "tooling"` — misclassified, and silently. + +`publication` fills the gap as a **durable** flavor: repos whose purpose is to +publish and keep a body of authored content for readers, where the corpus itself +is the deliverable. + +**Population is currently one.** A scan of all 131 registered repos found no +other true publication — `info-tech-canon` and `shard-wiki` are services that +handle documents rather than published corpora. That is an argument for adding +the category once and carefully, not for skipping it: the alternative is +misfiling a permanent record as transient project work. + +**Version: 1.1, not 2.0.** §17 currently reads "changed allowed values" as a +major bump. This addition is purely additive — no existing classification +becomes invalid, and neither validator enforces a version match, so the 125 +repo files declaring `version: '1.0'` keep validating. T01 clarifies §17 to +distinguish adding a permitted value (minor) from renaming or removing one +(major), rather than leaving the rule silently contradicted. + +## Amend the standard and its machine-readable vocabulary + +```task +id: CUST-WP-0069-T01 +status: todo +priority: high +``` + +In `canon/standards/repo-classification-standard_v1.0.md`: + +- add `### 5.7 publication` following the shape of the existing entries — main + question, typical signs, examples — and the disambiguation against `research` + and `product`; +- add `publication` to the §5 allowed-values block and to §3's field overview + where categories are listed; +- clarify §17 so that adding a permitted value is a minor bump; +- bump `version` in the frontmatter and the §17 current-version block to `1.1`. + +Keep the filename at `_v1.0.md` unless the canon's own convention says +otherwise; check how previous minor bumps were handled before renaming. + +In `canon/standards/repo-classification.allowed.yaml`: + +- add `publication` to `categories`; +- add `history` and `participation` to the `knowledge_and_evidence` capability + family, so hall-of-helix's tags do not warn as unrecognised; +- bump `version` to `1.1`. + +## Teach repo-manager the new category + +```task +id: CUST-WP-0069-T02 +status: todo +priority: high +``` + +Three hardcoded lists in `~/repo-manager`, plus tests: + +- `src/repo_manager/classification.py` — `CATEGORIES` frozenset; +- `src/repo_manager/standards.py` — add to `DURABLE_FLAVORS` (it is durable, so + `CATEGORIES` picks it up automatically); +- `src/repo_manager/cli.py` — `--category` choices. + +Run the repo-manager test suite. Track under a companion `RMGR-WP` if the change +turns out to be more than a vocabulary addition. + +## Classify hall-of-helix + +```task +id: CUST-WP-0069-T03 +status: todo +priority: medium +``` + +Write `hall-of-helix/.repo-classification.yaml`: + +```yaml +category: publication +domain: infotech +secondary_domains: [agents] +capability_tags: [knowledge, documentation, history, participation] +business_stake: [technology, people] +business_mechanics: [coordination, intention] +``` + +`participation` is the hall's own word — "we remember participation, not rank" — +and avoids the compensation framing that "credits" would import. `people` in +`business_stake` is deliberate and rare in the fleet: the hall exists to +acknowledge participants, and classifying it as purely `technology` would +describe the filesystem rather than the purpose. + +Clears C-24 and C-35 on that repo. Verify with the canon linter +(`tools/validate_repo_classification.py`) and `statehub fix-consistency`.