---
id: CUST-WP-0070
type: workplan
title: "Add the publication category to the Repo Classification Standard"
domain: infotech
repo: the-custodian
status: finished
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_dod: DoD-Ok
quality_dod_at: "2026-09-05"
quality_dod_by: claude-code
quality_dod_note: "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."
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
state_hub_workstream_id: "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

```task
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

```task
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

```task
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`:

```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`.