v1.2.0 — add spec/plan/overview/registry types, ledger anchoring, examples, bugfixes

[glandua]

Summary

Proposes KOI Naming Convention Manifesto v1.2.0 — a minor-version update (no breaking changes) addressing four concrete gaps observed while operationalizing RegenOS.

• 4 new object types — spec, plan, overview, registry — codified from real use-cases that had no clean home in v1.1.0
• New §Ledger Anchoring section — when/how to elevate KOI objects to content-addressable Regen Ledger RIDs, with rename discipline and §Legacy Names grandfathering
• New examples/ directory — one worked example per new type, serving as the CONTRIBUTING.md minimum-3-object pilot set
• Two small bugfixes — docs/semantic-naming-properties.md broken example, CONTRIBUTING.md missing heading prefix

Why Each Change

Each addition is grounded in a specific concrete artifact from today's RegenOS Phase 0 session (2026-04-21 builders-standup prep). No hallucinated practice — every claim traces to a file that now exists.

spec type

Today I needed to name an agentic loop specification defining three closed-loop patterns (GTM thesis loop, ai-ops-harness retro loop, engineering-product Spec Gate loop). No v1.1.0 type fit — docs is too general (this is implementation-ready, not reference material); strategy is forward-looking framework (this is a spec to execute against). spec fills the gap.

plan type

The 2026-04-17 mainnet-anchored artifact strategy.plan.claims-engine-dogfood-plan.v0.1.0 already uses plan as its type in practice, but plan wasn't in v1.1.0's type list (and incidentally that anchor uses a non-canonical first field — see §Legacy Names). Codifying plan aligns the manifesto with existing anchored practice. A plan differs from strategy: strategy is the framework (why + what); plan is the execution sequence (when + who + gates).

overview type

Top-level explainers of a system or domain at a point in time. Not a readme (those are entry-point navigation for a directory); not a strategy (those are forward-looking); not a memo (those originate a position). Grounded in today's regen-os-overview-v0.1.md artifact.

registry type

Meta-documents whose primary content is the index itself — not the content of what's indexed. Grounded in today's 45-artifact IRI/URL/RID registry. Downstream agents use it as a lookup table. Updates follow an add-a-row cadence, not a revise-the-prose cadence. Distinct from reference docs.

§Ledger Anchoring section

regen-signing shipped 2026-04-17, produced 4 mainnet anchors on regen-1 (Apr 17/18). Anchoring a KOI object produces a canonical/manifest/receipt triad via MsgAnchor. v1.1.0 was silent on this entire discipline. The new section also documents rename discipline — anchored files are rename-hostile because modifying the file modifies its content hash, silently invalidating the on-chain anchor. A manifesto-level classification procedure (anchored-historical vs. forward-reference vs. anchored-living) prevents this failure mode.

§Legacy Names

On-chain anchors predating v1.2.0 ratification use first fields that aren't canonical relevance values (e.g., strategy.plan.claims-engine-dogfood-plan.v0.1.0 where strategy is a type, not a relevance). These cannot be retroactively corrected without invalidating the anchor. The section formalizes grandfathering — legacy names preserved as historical record; all new anchored objects use canonical [relevance].[type].[subject].vX.Y.Z going forward.

Pilot Evidence

CONTRIBUTING.md requires a minimum of 3 objects using the proposed convention, piloted for at least 2 weeks. This PR includes 4 RegenOS Phase 0 artifacts as the pilot set — one per new type — all produced today (2026-04-21) as part of the RegenOS unified-operating-system scaffolding session:

KOI Name	Type	Pilot In
core.spec.regen-os-learning-subroutines.v0.1.0	spec	KOI Repo + examples/
core.plan.regen-os-phase-delivery.v0.1.0	plan	examples/
core.overview.regen-os-current-state.v0.1.0	overview	examples/
core.registry.regen-os-artifact-registry.v0.1.0	registry	KOI Repo + examples/

Plus an additional canonical entry already in the KOI Repo: core.strategy.regen-os-overview.v0.1.0 (valid under v1.1.0; companion to the four v1.2.0 pilots).

Pilot duration note: this is day zero of piloting. Proposing the PR for review now, with the governance call as the ratification forum. Pilot can continue during the review window to satisfy the 2-week minimum before ratification.

Bugfixes

docs/semantic-naming-properties.md — the worked example core.objective.rnd-foundation-sprint.v2025-Q2.v0.1.4 (appearing in three places: Notion property table, Google Docs metadata block, GitHub YAML frontmatter) had three issues:

1. objective is not a defined type in any version of the manifesto
2. v2025-Q2.v0.1.4 is a double-version — the versioning scheme is single-semver
3. Status: active is not in the canonical status list (draft/in review/ready to publish/published)

Replaced all three occurrences with a canonical v1.2.0 example: core.strategy.regen-os-overview.v0.1.0.

CONTRIBUTING.md — the "Who Can Contribute?" section header was missing its ## prefix (line 6), breaking Markdown rendering. Restored.

Scope Check

Version bump is minor (v1.1.0 → v1.2.0):

• No breaking changes
• All existing v1.0.0 and v1.1.0 names remain valid
• New types are additions, not replacements
• §Ledger Anchoring and §Legacy Names formalize practices that were already implicitly in use
• Bugfixes are corrective, not interpretive

Test Plan

• Manifesto v1.2.0 reads cleanly end-to-end; examples in §Naming Structure reference real pilots
• All 4 examples/ files exist, have valid frontmatter, and demonstrate their type's structural conventions
• examples/README.md links to each pilot
• README.md repository structure diagram reflects the new files
• changelog.md v1.2.0 entry follows Keep-a-Changelog format
• docs/semantic-naming-properties.md has no remaining broken examples (verify by searching core.objective, v2025-Q2, Status: active)
• CONTRIBUTING.md "Who Can Contribute?" heading renders as a section header
• Governance call review — surface in weekly KOI governance call for ratification feedback
• Pilot extension — at least one more use of each new type by a second contributor before ratification (per CONTRIBUTING.md)

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request updates the Knowledge Organization Infrastructure (KOI) naming convention to version 1.2.0. Key additions include four new object types—spec, plan, overview, and registry—along with a new section on ledger anchoring and rename discipline for anchored artifacts. The PR also introduces a directory of pilot examples and fixes several documentation inconsistencies. Review feedback correctly identified a naming mismatch between the manifesto examples and the pilot files, as well as a conceptual error in the legacy naming section regarding the classification of the "strategy" type.

[gemini-code-assist]

The example core.overview.regen-commons-current-state.v0.1.0 is inconsistent with the pilot name used in the types table (line 83) and the actual pilot file in the examples/ directory (core.overview.regen-os-current-state.v0.1.0). Updating this for consistency ensures the manifesto accurately reflects the pilot set.

Suggested change

	core.overview.regen-commons-current-state.v0.1.0
	core.overview.regen-os-current-state.v0.1.0

[gemini-code-assist]

The parenthetical note states that strategy is neither a canonical relevance nor type. However, strategy is explicitly defined as a canonical type in the v1.1.0 section (line 67). The issue with the legacy name is that a type was used in the relevance field, not that the term itself is unrecognized. The text should be corrected to avoid confusing readers about the validity of the strategy type.

Suggested change

Some objects anchored prior to v1.2.0 ratification use a **non-canonical first field** (e.g., `strategy.plan.claims-engine-dogfood-plan.v0.1.0` where `strategy` is neither a canonical relevance nor type). These legacy names are preserved as historical record — the ledger anchor is the authoritative identity of the object, and the on-chain record cannot be retroactively corrected without invalidating the anchor.

Some objects anchored prior to v1.2.0 ratification use a **non-canonical first field** (e.g., strategy.plan.claims-engine-dogfood-plan.v0.1.0 where strategy is a type, not a canonical relevance level). These legacy names are preserved as historical record — the ledger anchor is the authoritative identity of the object, and the on-chain record cannot be retroactively corrected without invalidating the anchor.