the-custodian/workplans/CUST-WP-0070-publication-repo-category.md

id	type	title	domain	repo	status	owner	topic_slug	priority	created	updated	quality_dor	quality_dor_at	quality_dor_by	quality_dod	quality_dod_at	quality_dod_by	quality_dod_note	quality_dor_note	related	state_hub_workstream_id
CUST-WP-0070	workplan	Add the publication category to the Repo Classification Standard	infotech	the-custodian	finished	claude-code	custodian	medium	2026-09-05	2026-09-05	DoR-Ok	2026-09-05	claude-code	DoD-Ok	2026-09-05	claude-code	Standard at v1.1 with §5.7, the §5 vocabulary, §11 decision procedure, §16 agent prompt and §17 versioning rule updated; allowed.yaml carries publication plus history/participation in knowledge_and_evidence. repo-manager updated in classification.py, standards.py (DURABLE_FLAVORS) and cli.py — full suite 161 passed. hall-of-helix classified: canon linter ok, fix-consistency 0 warns, resolve_flavor now returns publication where it previously fell through to tooling.	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.	HOH-WP-0001	6d11d4fd-9882-55db-9010-b35754434b54

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

id: CUST-WP-0070-T01
status: done
priority: high
state_hub_task_id: "75f56501-1416-5ab4-9d91-405ae532ac6b"

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

id: CUST-WP-0070-T02
status: done
priority: high
state_hub_task_id: "6c943dec-f676-57af-a004-8c40b0ddebc1"

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

id: CUST-WP-0070-T03
status: done
priority: medium
state_hub_task_id: "0661c1d4-20e5-5d02-9435-eae171b07e13"

Write hall-of-helix/.repo-classification.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.