REUSE-WP-0015: dedup owner entries, add report gaps (T02/T03/T05)
Some checks failed
ci / validate-registry (push) Has been cancelled

Remove 17 owner-migrated capabilities from reuse-surface index (keep
activity-core stub). Add report gaps CLI, roster stats + gaps CI steps.
T01 remains operator-blocked on Gitea publish.
This commit is contained in:
2026-06-16 02:22:17 +02:00
parent 660e2acfb8
commit 81c55e598f
32 changed files with 259 additions and 2660 deletions

View File

@@ -35,8 +35,16 @@ jobs:
- name: Registry stats (informational)
run: reuse-surface stats || true
- name: Workstation roster federation stats (informational)
run: |
reuse-surface stats --roster registry/federation/local-repo-roster.yaml \
--federation-ready --format json || true
- name: Planning cohort report (informational)
run: reuse-surface report cohorts --planning-min D4 || true
- name: Registry gap report (informational)
run: reuse-surface report gaps || true
- name: Run tests
run: pytest -q

View File

@@ -60,6 +60,8 @@ The MVP registry foundation, CLI tooling (REUSE-WP-0003), federation stack
against `https://reuse.coulomb.social`
- **Sync local federation manifest from hub** with `reuse-surface hub sync`
- **Export planning cohorts** with `reuse-surface report cohorts`
- **Report registry gaps** with `reuse-surface report gaps` (roster blockers,
empty scaffolds, dedup stubs)
- **Bootstrap a sibling registry** with `reuse-surface establish --scaffold`
- **Verify index publish readiness** with `reuse-surface establish --publish-check`
- **View registry stats** with `reuse-surface stats` (per-repo or
@@ -101,8 +103,9 @@ See `tools/README.md` for command reference.
- **Status:** active MVP registry with CLI, federation, production hub, and
workstation-wide registry rollout (REUSE-WP-0014 finished).
- **Capabilities (reuse-surface):** 20 helix_forge entries in
`registry/capabilities/` (18 owner-migrated; dedup pending).
- **Capabilities (reuse-surface):** 3 helix_forge entries in
`registry/capabilities/` (2 meta-registry + 1 `activity-core` stub until
publish passes).
- **Workstation roster:** 60 local git repos at `~/<slug>/` tracked in
`registry/federation/local-repo-roster.yaml` — all **established**, **60/60**
hub-registered, **47/60** publish-check pass.

View File

@@ -1,8 +1,8 @@
# Capability Catalog
**Domain:** helix_forge
**Updated:** 2026-06-15
**Entries:** 20
**Updated:** 2026-06-16
**Entries:** 3
Generated by `reuse-surface catalog`. Do not edit manually.
@@ -19,85 +19,6 @@ Generated by `reuse-surface catalog`. Do not edit manually.
**Known limitations:**
- early discovery stage
### Audit Event Retention
- **ID:** `capability.audit.event-retain`
- **Vector:** D4 / A2 / C2 / R1
- **Owner:** audit-core
- **Path:** `registry/capabilities/capability.audit.event-retain.md`
- **Summary:** Collect, normalize, retain, and search audit events with integrity evidence across tenants.
**Known limitations:**
- consumer evidence not yet collected in registry
### Authorization Policy Evaluation
- **ID:** `capability.authorization.policy-evaluate`
- **Vector:** D4 / A2 / C2 / R1
- **Owner:** flex-auth
- **Path:** `registry/capabilities/capability.authorization.policy-evaluate.md`
- **Summary:** Evaluate access decisions from policy-as-code rules for subjects, resources, and actions.
**Known limitations:**
- maturity evidence is registry-external today
### Feature Availability Evaluation
- **ID:** `capability.feature-control.evaluate`
- **Vector:** D5 / A4 / C3 / R3
- **Owner:** feature-control
- **Path:** `registry/capabilities/capability.feature-control.evaluate.md`
- **Summary:** Evaluate whether a feature is active, hidden, disabled, or unavailable for a subject in context.
**Known limitations:**
- bulk rule management is not yet covered
- agent-specific simulation remains a known gap
### Feature Rollout Control
- **ID:** `capability.feature-control.rollout`
- **Vector:** D4 / A2 / C2 / R1
- **Owner:** feature-control
- **Path:** `registry/capabilities/capability.feature-control.rollout.md`
- **Summary:** Gradually expose features to subjects across tenants, domains, groups, or cohorts using rollout rules.
**Known limitations:**
- distinguish carefully from capability.feature-control.evaluate
### Feature Visibility Control
- **ID:** `capability.feature-control.visibility`
- **Vector:** D4 / A2 / C2 / R1
- **Owner:** feature-control
- **Path:** `registry/capabilities/capability.feature-control.visibility.md`
- **Summary:** Control whether features are visible or hidden for subjects without changing entitlement or authorization.
**Known limitations:**
- implementation may be bundled with evaluate SDK today
### Identity Subject Resolution
- **ID:** `capability.identity.subject-resolution`
- **Vector:** D3 / A0 / C1 / R0
- **Owner:** identity-canon
- **Path:** `registry/capabilities/capability.identity.subject-resolution.md`
- **Summary:** Resolve who or what is acting by mapping principals, accounts, actors, and identifiers to a stable subject model.
**Known limitations:**
- resolver artifacts are not yet available
### Identity Vocabulary Canonicalization
- **ID:** `capability.identity.vocabulary-canonicalize`
- **Vector:** D4 / A0 / C2 / R0
- **Owner:** identity-canon
- **Path:** `registry/capabilities/capability.identity.vocabulary-canonicalize.md`
- **Summary:** Define an implementation-neutral vocabulary for identity-related concepts across overlapping domains.
**Known limitations:**
- source-note backfill is incomplete
- mappings may remain candidate until evidence review completes
### Capability Registration
- **ID:** `capability.registry.register`
@@ -120,113 +41,3 @@ Generated by `reuse-surface catalog`. Do not edit manually.
**Known limitations:**
- warnings do not fail CI unless --fail-on-warnings is set
### Work Progress Logging
- **ID:** `capability.statehub.progress-log`
- **Vector:** D4 / A4 / C3 / R3
- **Owner:** state-hub
- **Path:** `registry/capabilities/capability.statehub.progress-log.md`
- **Summary:** Record progress events, decisions, and session notes against workstreams and tasks in State Hub.
**Known limitations:**
- hub must be running locally or via tunnel
### Workstream And Task Coordination
- **ID:** `capability.statehub.workstream-coordinate`
- **Vector:** D4 / A4 / C3 / R2
- **Owner:** state-hub
- **Path:** `registry/capabilities/capability.statehub.workstream-coordinate.md`
- **Summary:** Track active workstreams, tasks, progress, and consistency across domain repositories.
**Known limitations:**
- requires running State Hub locally or via tunnel
### Capability-Aware Shard Adapter Contract
- **ID:** `capability.wiki.adapter-contract`
- **Vector:** D5 / A2 / C2 / R1
- **Owner:** shard-wiki
- **Path:** `registry/capabilities/capability.wiki.adapter-contract.md`
- **Summary:** A versioned backend interface where each binding declares a verified capability profile, so federation ops degrade by capability.
**Known limitations:**
- reference implementation covers the file-store substrate only so far
### Event-Sourced Coordination Journal
- **ID:** `capability.wiki.coordination-journal`
- **Vector:** D5 / A2 / C2 / R1
- **Owner:** shard-wiki
- **Path:** `registry/capabilities/capability.wiki.coordination-journal.md`
- **Summary:** An append-only, totally-ordered-per-space decision log whose current state is a derived fold; git-addressable history.
**Known limitations:**
- production git backing + lease are still on the roadmap (SHARD-WP-0009)
### Wiki Derived Views
- **ID:** `capability.wiki.derived-views`
- **Vector:** D3 / A0 / C0 / R0
- **Owner:** shard-wiki
- **Path:** `registry/capabilities/capability.wiki.derived-views.md`
- **Summary:** Recomputable views over a wiki union — BackLinks, RecentChanges, AllPages, SiteMap, and (delegate-or-derive) Search — carrying provenance.
**Known limitations:**
- not implemented; Search ranking policy undecided
### Wiki Engine with Typed Extensions
- **ID:** `capability.wiki.engine-typed-extensions`
- **Vector:** D3 / A0 / C0 / R0
- **Owner:** shard-wiki
- **Path:** `registry/capabilities/capability.wiki.engine-typed-extensions.md`
- **Summary:** A small-core wiki engine realizing a typed-extension framework that addresses all wiki use cases and lets each shard activate only the features it needs.
**Known limitations:**
- architecture authored; extension SDK/ABI + API protocol still to design; not yet built
### Selectable Federation-Model Taxonomy
- **ID:** `capability.wiki.federation-models`
- **Vector:** D4 / A0 / C1 / R0
- **Owner:** shard-wiki
- **Path:** `registry/capabilities/capability.wiki.federation-models.md`
- **Summary:** Federation as a plural, composable coordination axis (fork+journal, VCS-replication, query-join, feed, activity-streams, engine-mirror) selected per space.
**Known limitations:**
- no transport implemented; informational planning reuse only
### Overlay-Before-Mutation Write Path
- **ID:** `capability.wiki.overlay`
- **Vector:** D5 / A2 / C2 / R1
- **Owner:** shard-wiki
- **Path:** `registry/capabilities/capability.wiki.overlay.md`
- **Summary:** Non-destructive edits (draft -> patch -> apply-under-drift) that let read-only or limited backends be edited safely without silent remote mutation.
**Known limitations:**
- merge is detect-and-refuse; three-way merge is future work
### Backend-Neutral Wiki Page Model
- **ID:** `capability.wiki.page-model`
- **Vector:** D5 / A2 / C2 / R1
- **Owner:** shard-wiki
- **Path:** `registry/capabilities/capability.wiki.page-model.md`
- **Summary:** A Markdown-first but stretchable page model with stable identity separate from placement and layered provenance.
**Known limitations:**
- non-prose shapes specified ahead of implementation
### Wiki Shard Orchestration
- **ID:** `capability.wiki.shard-orchestration`
- **Vector:** D5 / A2 / C2 / R1
- **Owner:** shard-wiki
- **Path:** `registry/capabilities/capability.wiki.shard-orchestration.md`
- **Summary:** Present a union of pages across heterogeneous wiki-shaped shards while preserving each shard's provenance, capabilities, and history.
**Known limitations:**
- resolution is recompute-on-read until the incremental tier lands

View File

@@ -15,7 +15,7 @@
</head>
<body>
<h1>Capability Catalog</h1>
<p class="subtitle">Updated 2026-06-15 · 20 entries</p>
<p class="subtitle">Updated 2026-06-16 · 3 entries</p>
<section><h2>helix_forge</h2>
<article class="card">
<h3>Organizational Event Coordination</h3>
@@ -23,48 +23,6 @@
<p>Coordinate structured responses to cross-domain events through activity workflows and automation.</p>
<p class="path">registry/capabilities/capability.activity.event-coordinate.md</p>
</article>
<article class="card">
<h3>Audit Event Retention</h3>
<p class="meta"><code>capability.audit.event-retain</code> · D4 / A2 / C2 / R1</p>
<p>Collect, normalize, retain, and search audit events with integrity evidence across tenants.</p>
<p class="path">registry/capabilities/capability.audit.event-retain.md</p>
</article>
<article class="card">
<h3>Authorization Policy Evaluation</h3>
<p class="meta"><code>capability.authorization.policy-evaluate</code> · D4 / A2 / C2 / R1</p>
<p>Evaluate access decisions from policy-as-code rules for subjects, resources, and actions.</p>
<p class="path">registry/capabilities/capability.authorization.policy-evaluate.md</p>
</article>
<article class="card">
<h3>Feature Availability Evaluation</h3>
<p class="meta"><code>capability.feature-control.evaluate</code> · D5 / A4 / C3 / R3</p>
<p>Evaluate whether a feature is active, hidden, disabled, or unavailable for a subject in context.</p>
<p class="path">registry/capabilities/capability.feature-control.evaluate.md</p>
</article>
<article class="card">
<h3>Feature Rollout Control</h3>
<p class="meta"><code>capability.feature-control.rollout</code> · D4 / A2 / C2 / R1</p>
<p>Gradually expose features to subjects across tenants, domains, groups, or cohorts using rollout rules.</p>
<p class="path">registry/capabilities/capability.feature-control.rollout.md</p>
</article>
<article class="card">
<h3>Feature Visibility Control</h3>
<p class="meta"><code>capability.feature-control.visibility</code> · D4 / A2 / C2 / R1</p>
<p>Control whether features are visible or hidden for subjects without changing entitlement or authorization.</p>
<p class="path">registry/capabilities/capability.feature-control.visibility.md</p>
</article>
<article class="card">
<h3>Identity Subject Resolution</h3>
<p class="meta"><code>capability.identity.subject-resolution</code> · D3 / A0 / C1 / R0</p>
<p>Resolve who or what is acting by mapping principals, accounts, actors, and identifiers to a stable subject model.</p>
<p class="path">registry/capabilities/capability.identity.subject-resolution.md</p>
</article>
<article class="card">
<h3>Identity Vocabulary Canonicalization</h3>
<p class="meta"><code>capability.identity.vocabulary-canonicalize</code> · D4 / A0 / C2 / R0</p>
<p>Define an implementation-neutral vocabulary for identity-related concepts across overlapping domains.</p>
<p class="path">registry/capabilities/capability.identity.vocabulary-canonicalize.md</p>
</article>
<article class="card">
<h3>Capability Registration</h3>
<p class="meta"><code>capability.registry.register</code> · D3 / A4 / C2 / R3</p>
@@ -76,66 +34,6 @@
<p class="meta"><code>capability.registry.validate</code> · D4 / A3 / C3 / R3</p>
<p>Validate capability registry entries against schema, index consistency, and relation integrity.</p>
<p class="path">registry/capabilities/capability.registry.validate.md</p>
</article>
<article class="card">
<h3>Work Progress Logging</h3>
<p class="meta"><code>capability.statehub.progress-log</code> · D4 / A4 / C3 / R3</p>
<p>Record progress events, decisions, and session notes against workstreams and tasks in State Hub.</p>
<p class="path">registry/capabilities/capability.statehub.progress-log.md</p>
</article>
<article class="card">
<h3>Workstream And Task Coordination</h3>
<p class="meta"><code>capability.statehub.workstream-coordinate</code> · D4 / A4 / C3 / R2</p>
<p>Track active workstreams, tasks, progress, and consistency across domain repositories.</p>
<p class="path">registry/capabilities/capability.statehub.workstream-coordinate.md</p>
</article>
<article class="card">
<h3>Capability-Aware Shard Adapter Contract</h3>
<p class="meta"><code>capability.wiki.adapter-contract</code> · D5 / A2 / C2 / R1</p>
<p>A versioned backend interface where each binding declares a verified capability profile, so federation ops degrade by capability.</p>
<p class="path">registry/capabilities/capability.wiki.adapter-contract.md</p>
</article>
<article class="card">
<h3>Event-Sourced Coordination Journal</h3>
<p class="meta"><code>capability.wiki.coordination-journal</code> · D5 / A2 / C2 / R1</p>
<p>An append-only, totally-ordered-per-space decision log whose current state is a derived fold; git-addressable history.</p>
<p class="path">registry/capabilities/capability.wiki.coordination-journal.md</p>
</article>
<article class="card">
<h3>Wiki Derived Views</h3>
<p class="meta"><code>capability.wiki.derived-views</code> · D3 / A0 / C0 / R0</p>
<p>Recomputable views over a wiki union — BackLinks, RecentChanges, AllPages, SiteMap, and (delegate-or-derive) Search — carrying provenance.</p>
<p class="path">registry/capabilities/capability.wiki.derived-views.md</p>
</article>
<article class="card">
<h3>Wiki Engine with Typed Extensions</h3>
<p class="meta"><code>capability.wiki.engine-typed-extensions</code> · D3 / A0 / C0 / R0</p>
<p>A small-core wiki engine realizing a typed-extension framework that addresses all wiki use cases and lets each shard activate only the features it needs.</p>
<p class="path">registry/capabilities/capability.wiki.engine-typed-extensions.md</p>
</article>
<article class="card">
<h3>Selectable Federation-Model Taxonomy</h3>
<p class="meta"><code>capability.wiki.federation-models</code> · D4 / A0 / C1 / R0</p>
<p>Federation as a plural, composable coordination axis (fork+journal, VCS-replication, query-join, feed, activity-streams, engine-mirror) selected per space.</p>
<p class="path">registry/capabilities/capability.wiki.federation-models.md</p>
</article>
<article class="card">
<h3>Overlay-Before-Mutation Write Path</h3>
<p class="meta"><code>capability.wiki.overlay</code> · D5 / A2 / C2 / R1</p>
<p>Non-destructive edits (draft -&gt; patch -&gt; apply-under-drift) that let read-only or limited backends be edited safely without silent remote mutation.</p>
<p class="path">registry/capabilities/capability.wiki.overlay.md</p>
</article>
<article class="card">
<h3>Backend-Neutral Wiki Page Model</h3>
<p class="meta"><code>capability.wiki.page-model</code> · D5 / A2 / C2 / R1</p>
<p>A Markdown-first but stretchable page model with stable identity separate from placement and layered provenance.</p>
<p class="path">registry/capabilities/capability.wiki.page-model.md</p>
</article>
<article class="card">
<h3>Wiki Shard Orchestration</h3>
<p class="meta"><code>capability.wiki.shard-orchestration</code> · D5 / A2 / C2 / R1</p>
<p>Present a union of pages across heterogeneous wiki-shaped shards while preserving each shard&#x27;s provenance, capabilities, and history.</p>
<p class="path">registry/capabilities/capability.wiki.shard-orchestration.md</p>
</article></section>
</body>
</html>

View File

@@ -1,6 +1,6 @@
{
"domain": "helix_forge",
"updated": "2026-06-15",
"updated": "2026-06-16",
"capabilities": [
{
"id": "capability.activity.event-coordinate",
@@ -20,133 +20,6 @@
"informational"
]
},
{
"id": "capability.audit.event-retain",
"name": "Audit Event Retention",
"summary": "Collect, normalize, retain, and search audit events with integrity evidence across tenants.",
"vector": "D4 / A2 / C2 / R1",
"domain": "helix_forge",
"status": "draft",
"owner": "audit-core",
"path": "registry/capabilities/capability.audit.event-retain.md",
"tags": [
"audit",
"retention",
"compliance"
],
"consumption_modes": [
"source module"
]
},
{
"id": "capability.authorization.policy-evaluate",
"name": "Authorization Policy Evaluation",
"summary": "Evaluate access decisions from policy-as-code rules for subjects, resources, and actions.",
"vector": "D4 / A2 / C2 / R1",
"domain": "helix_forge",
"status": "draft",
"owner": "flex-auth",
"path": "registry/capabilities/capability.authorization.policy-evaluate.md",
"tags": [
"authorization",
"policy",
"flex-auth"
],
"consumption_modes": [
"source module"
]
},
{
"id": "capability.feature-control.evaluate",
"name": "Feature Availability Evaluation",
"summary": "Evaluate whether a feature is active, hidden, disabled, or unavailable for a subject in context.",
"vector": "D5 / A4 / C3 / R3",
"domain": "helix_forge",
"status": "draft",
"owner": "feature-control",
"path": "registry/capabilities/capability.feature-control.evaluate.md",
"tags": [
"feature-control",
"evaluation",
"sdk"
],
"consumption_modes": [
"SDK",
"service API"
]
},
{
"id": "capability.feature-control.rollout",
"name": "Feature Rollout Control",
"summary": "Gradually expose features to subjects across tenants, domains, groups, or cohorts using rollout rules.",
"vector": "D4 / A2 / C2 / R1",
"domain": "helix_forge",
"status": "draft",
"owner": "feature-control",
"path": "registry/capabilities/capability.feature-control.rollout.md",
"tags": [
"feature-control",
"rollout",
"planning"
],
"consumption_modes": [
"source module",
"SDK"
]
},
{
"id": "capability.feature-control.visibility",
"name": "Feature Visibility Control",
"summary": "Control whether features are visible or hidden for subjects without changing entitlement or authorization.",
"vector": "D4 / A2 / C2 / R1",
"domain": "helix_forge",
"status": "draft",
"owner": "feature-control",
"path": "registry/capabilities/capability.feature-control.visibility.md",
"tags": [
"feature-control",
"visibility"
],
"consumption_modes": [
"source module"
]
},
{
"id": "capability.identity.subject-resolution",
"name": "Identity Subject Resolution",
"summary": "Resolve who or what is acting by mapping principals, accounts, actors, and identifiers to a stable subject model.",
"vector": "D3 / A0 / C1 / R0",
"domain": "helix_forge",
"status": "draft",
"owner": "identity-canon",
"path": "registry/capabilities/capability.identity.subject-resolution.md",
"tags": [
"identity",
"subject",
"architecture"
],
"consumption_modes": [
"informational"
]
},
{
"id": "capability.identity.vocabulary-canonicalize",
"name": "Identity Vocabulary Canonicalization",
"summary": "Define an implementation-neutral vocabulary for identity-related concepts across overlapping domains.",
"vector": "D4 / A0 / C2 / R0",
"domain": "helix_forge",
"status": "draft",
"owner": "identity-canon",
"path": "registry/capabilities/capability.identity.vocabulary-canonicalize.md",
"tags": [
"identity",
"terminology",
"research"
],
"consumption_modes": [
"informational"
]
},
{
"id": "capability.registry.register",
"name": "Capability Registration",
@@ -185,208 +58,6 @@
"consumption_modes": [
"cli"
]
},
{
"id": "capability.statehub.progress-log",
"name": "Work Progress Logging",
"summary": "Record progress events, decisions, and session notes against workstreams and tasks in State Hub.",
"vector": "D4 / A4 / C3 / R3",
"domain": "helix_forge",
"status": "draft",
"owner": "state-hub",
"path": "registry/capabilities/capability.statehub.progress-log.md",
"tags": [
"state-hub",
"progress",
"coordination"
],
"consumption_modes": [
"service API"
]
},
{
"id": "capability.statehub.workstream-coordinate",
"name": "Workstream And Task Coordination",
"summary": "Track active workstreams, tasks, progress, and consistency across domain repositories.",
"vector": "D4 / A4 / C3 / R2",
"domain": "helix_forge",
"status": "draft",
"owner": "state-hub",
"path": "registry/capabilities/capability.statehub.workstream-coordinate.md",
"tags": [
"state-hub",
"coordination",
"workplans"
],
"consumption_modes": [
"service API",
"HTTP REST"
]
},
{
"id": "capability.wiki.shard-orchestration",
"name": "Wiki Shard Orchestration",
"summary": "Present a union of pages across heterogeneous wiki-shaped shards while preserving each shard's provenance, capabilities, and history.",
"vector": "D5 / A2 / C2 / R1",
"domain": "helix_forge",
"status": "draft",
"owner": "shard-wiki",
"path": "registry/capabilities/capability.wiki.shard-orchestration.md",
"tags": [
"wiki",
"federation",
"orchestration",
"union",
"shard-wiki"
],
"consumption_modes": [
"source module"
]
},
{
"id": "capability.wiki.adapter-contract",
"name": "Capability-Aware Shard Adapter Contract",
"summary": "A versioned backend interface where each binding declares a verified capability profile, so federation ops degrade by capability.",
"vector": "D5 / A2 / C2 / R1",
"domain": "helix_forge",
"status": "draft",
"owner": "shard-wiki",
"path": "registry/capabilities/capability.wiki.adapter-contract.md",
"tags": [
"wiki",
"adapter",
"capability",
"contract",
"conformance",
"shard-wiki"
],
"consumption_modes": [
"source module"
]
},
{
"id": "capability.wiki.page-model",
"name": "Backend-Neutral Wiki Page Model",
"summary": "A Markdown-first but stretchable page model with stable identity separate from placement and layered provenance.",
"vector": "D5 / A2 / C2 / R1",
"domain": "helix_forge",
"status": "draft",
"owner": "shard-wiki",
"path": "registry/capabilities/capability.wiki.page-model.md",
"tags": [
"wiki",
"page-model",
"identity",
"provenance",
"markdown",
"shard-wiki"
],
"consumption_modes": [
"source module"
]
},
{
"id": "capability.wiki.coordination-journal",
"name": "Event-Sourced Coordination Journal",
"summary": "An append-only, totally-ordered-per-space decision log whose current state is a derived fold; git-addressable history.",
"vector": "D5 / A2 / C2 / R1",
"domain": "helix_forge",
"status": "draft",
"owner": "shard-wiki",
"path": "registry/capabilities/capability.wiki.coordination-journal.md",
"tags": [
"wiki",
"event-sourcing",
"coordination",
"git",
"journal",
"shard-wiki"
],
"consumption_modes": [
"source module"
]
},
{
"id": "capability.wiki.overlay",
"name": "Overlay-Before-Mutation Write Path",
"summary": "Non-destructive edits (draft -> patch -> apply-under-drift) that let read-only or limited backends be edited safely without silent remote mutation.",
"vector": "D5 / A2 / C2 / R1",
"domain": "helix_forge",
"status": "draft",
"owner": "shard-wiki",
"path": "registry/capabilities/capability.wiki.overlay.md",
"tags": [
"wiki",
"overlay",
"patch",
"write-path",
"conflict",
"shard-wiki"
],
"consumption_modes": [
"source module"
]
},
{
"id": "capability.wiki.federation-models",
"name": "Selectable Federation-Model Taxonomy",
"summary": "Federation as a plural, composable coordination axis (fork+journal, VCS-replication, query-join, feed, activity-streams, engine-mirror) selected per space.",
"vector": "D4 / A0 / C1 / R0",
"domain": "helix_forge",
"status": "draft",
"owner": "shard-wiki",
"path": "registry/capabilities/capability.wiki.federation-models.md",
"tags": [
"wiki",
"federation",
"taxonomy",
"composable",
"shard-wiki"
],
"consumption_modes": [
"informational"
]
},
{
"id": "capability.wiki.engine-typed-extensions",
"name": "Wiki Engine with Typed Extensions",
"summary": "A small-core wiki engine realizing a typed-extension framework that addresses all wiki use cases and lets each shard activate only the features it needs.",
"vector": "D3 / A0 / C0 / R0",
"domain": "helix_forge",
"status": "draft",
"owner": "shard-wiki",
"path": "registry/capabilities/capability.wiki.engine-typed-extensions.md",
"tags": [
"wiki",
"engine",
"typed-extensions",
"feature-activation",
"shard-wiki"
],
"consumption_modes": [
"informational"
]
},
{
"id": "capability.wiki.derived-views",
"name": "Wiki Derived Views",
"summary": "Recomputable views over a wiki union \u2014 BackLinks, RecentChanges, AllPages, SiteMap, and (delegate-or-derive) Search \u2014 carrying provenance.",
"vector": "D3 / A0 / C0 / R0",
"domain": "helix_forge",
"status": "draft",
"owner": "shard-wiki",
"path": "registry/capabilities/capability.wiki.derived-views.md",
"tags": [
"wiki",
"derived-views",
"backlinks",
"recentchanges",
"search",
"shard-wiki"
],
"consumption_modes": [
"informational"
]
}
]
}

View File

@@ -1,71 +1,11 @@
graph LR
capability_activity_event_coordinate["capability.activity.event-coordinate<br/>D3 / A1 / C1 / R0"]
capability_audit_event_retain["capability.audit.event-retain<br/>D4 / A2 / C2 / R1"]
capability_authorization_policy_evaluate["capability.authorization.policy-evaluate<br/>D4 / A2 / C2 / R1"]
capability_feature_control_evaluate["capability.feature-control.evaluate<br/>D5 / A4 / C3 / R3"]
capability_feature_control_rollout["capability.feature-control.rollout<br/>D4 / A2 / C2 / R1"]
capability_feature_control_visibility["capability.feature-control.visibility<br/>D4 / A2 / C2 / R1"]
capability_identity_subject_resolution["capability.identity.subject-resolution<br/>D3 / A0 / C1 / R0"]
capability_identity_vocabulary_canonicalize["capability.identity.vocabulary-canonicalize<br/>D4 / A0 / C2 / R0"]
capability_registry_register["capability.registry.register<br/>D3 / A4 / C2 / R3"]
capability_registry_validate["capability.registry.validate<br/>D4 / A3 / C3 / R3"]
capability_statehub_progress_log["capability.statehub.progress-log<br/>D4 / A4 / C3 / R3"]
capability_statehub_workstream_coordinate["capability.statehub.workstream-coordinate<br/>D4 / A4 / C3 / R2"]
capability_wiki_adapter_contract["capability.wiki.adapter-contract<br/>D5 / A2 / C2 / R1"]
capability_wiki_coordination_journal["capability.wiki.coordination-journal<br/>D5 / A2 / C2 / R1"]
capability_wiki_derived_views["capability.wiki.derived-views<br/>D3 / A0 / C0 / R0"]
capability_wiki_engine_typed_extensions["capability.wiki.engine-typed-extensions<br/>D3 / A0 / C0 / R0"]
capability_wiki_federation_models["capability.wiki.federation-models<br/>D4 / A0 / C1 / R0"]
capability_wiki_overlay["capability.wiki.overlay<br/>D5 / A2 / C2 / R1"]
capability_wiki_page_model["capability.wiki.page-model<br/>D5 / A2 / C2 / R1"]
capability_wiki_shard_orchestration["capability.wiki.shard-orchestration<br/>D5 / A2 / C2 / R1"]
capability_activity_event_coordinate -->|related_to| capability_statehub_workstream_coordinate
capability_activity_event_coordinate -->|related_to| capability_audit_event_retain
capability_audit_event_retain -->|related_to| capability_activity_event_coordinate
capability_audit_event_retain -->|related_to| capability_statehub_progress_log
capability_authorization_policy_evaluate -->|depends_on| capability_identity_subject_resolution
capability_authorization_policy_evaluate -->|related_to| capability_feature_control_evaluate
capability_feature_control_evaluate -->|depends_on| capability_identity_vocabulary_canonicalize
capability_feature_control_evaluate -->|supports| capability_registry_register
capability_feature_control_evaluate -->|related_to| capability_feature_control_rollout
capability_feature_control_evaluate -->|related_to| capability_feature_control_visibility
capability_feature_control_rollout -->|depends_on| capability_feature_control_evaluate
capability_feature_control_rollout -->|related_to| capability_feature_control_visibility
capability_feature_control_visibility -->|depends_on| capability_feature_control_evaluate
capability_feature_control_visibility -->|related_to| capability_feature_control_rollout
capability_identity_subject_resolution -->|depends_on| capability_identity_vocabulary_canonicalize
capability_identity_subject_resolution -->|supports| capability_feature_control_evaluate
capability_identity_subject_resolution -->|supports| capability_statehub_workstream_coordinate
capability_identity_vocabulary_canonicalize -->|supports| capability_feature_control_evaluate
capability_identity_vocabulary_canonicalize -->|supports| capability_registry_register
capability_identity_vocabulary_canonicalize -->|related_to| capability_identity_subject_resolution
capability_registry_register -->|supports| capability_feature_control_evaluate
capability_registry_register -->|supports| capability_identity_vocabulary_canonicalize
capability_registry_register -->|related_to| capability_registry_validate
capability_registry_validate -->|depends_on| capability_registry_register
capability_registry_validate -->|related_to| capability_registry_register
capability_statehub_progress_log -->|depends_on| capability_statehub_workstream_coordinate
capability_statehub_progress_log -->|related_to| capability_statehub_workstream_coordinate
capability_statehub_workstream_coordinate -->|supports| capability_registry_register
capability_statehub_workstream_coordinate -->|related_to| capability_statehub_progress_log
capability_wiki_shard_orchestration -->|depends_on| capability_wiki_adapter_contract
capability_wiki_shard_orchestration -->|depends_on| capability_wiki_page_model
capability_wiki_shard_orchestration -->|depends_on| capability_wiki_coordination_journal
capability_wiki_shard_orchestration -->|supports| capability_wiki_federation_models
capability_wiki_adapter_contract -->|depends_on| capability_wiki_page_model
capability_wiki_adapter_contract -->|supports| capability_wiki_shard_orchestration
capability_wiki_page_model -->|supports| capability_wiki_adapter_contract
capability_wiki_page_model -->|supports| capability_wiki_shard_orchestration
capability_wiki_coordination_journal -->|supports| capability_wiki_shard_orchestration
capability_wiki_coordination_journal -->|supports| capability_wiki_overlay
capability_wiki_overlay -->|depends_on| capability_wiki_coordination_journal
capability_wiki_overlay -->|depends_on| capability_wiki_adapter_contract
capability_wiki_federation_models -->|depends_on| capability_wiki_shard_orchestration
capability_wiki_federation_models -->|depends_on| capability_wiki_coordination_journal
capability_wiki_engine_typed_extensions -->|depends_on| capability_wiki_adapter_contract
capability_wiki_engine_typed_extensions -->|depends_on| capability_wiki_page_model
capability_wiki_engine_typed_extensions -->|related_to| capability_feature_control_evaluate
capability_wiki_engine_typed_extensions -->|related_to| capability_authorization_policy_evaluate
capability_wiki_derived_views -->|depends_on| capability_wiki_shard_orchestration
capability_wiki_derived_views -->|depends_on| capability_wiki_page_model
capability_wiki_derived_views -->|related_to| capability_wiki_engine_typed_extensions

File diff suppressed because one or more lines are too long

View File

@@ -1,80 +0,0 @@
---
id: capability.audit.event-retain
name: Audit Event Retention
summary: Collect, normalize, retain, and search audit events with integrity evidence across tenants.
owner: audit-core
status: draft
domain: helix_forge
tags: [audit, retention, compliance]
maturity:
discovery:
current: D4
target: D6
confidence: medium
rationale: audit-core INTENT defines full audit fabric scope and integration boundaries.
availability:
current: A2
target: A5
confidence: low
rationale: Core modules exist; deployable service packaging in progress.
external_evidence:
completeness:
level: C2
name: Partial
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- retention and integrity goals documented
broken_expectations:
- federation with all platform runtimes not proven in registry
out_of_scope_expectations:
- application business audit semantics ownership
reliability:
level: R1
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- multi-tenant isolation not evidenced here
discovery:
intent: >
Provide independent audit fabric for collecting, retaining, searching, and
proving integrity of audit events.
includes:
- audit ingestion
- retention policy
- search and export
- tamper evidence
excludes:
- generating domain business events
use_cases: []
availability:
current_level: A2
target_level: A5
current_artifacts:
- audit-core/
consumption_modes:
- source module
relations:
depends_on: []
related_to:
- capability.activity.event-coordinate
- capability.statehub.progress-log
consumer_guidance:
recommended_for:
- planning audit retention independent of a single product
not_recommended_for:
- replacing application-level logging only
known_limitations:
- consumer evidence not yet collected in registry
---
# Audit Event Retention
Audit Core provides the retention and integrity layer for audit events across
the platform.

View File

@@ -1,80 +0,0 @@
---
id: capability.authorization.policy-evaluate
name: Authorization Policy Evaluation
summary: Evaluate access decisions from policy-as-code rules for subjects, resources, and actions.
owner: flex-auth
status: draft
domain: helix_forge
tags: [authorization, policy, flex-auth]
maturity:
discovery:
current: D4
target: D6
confidence: medium
rationale: flex-auth INTENT defines policy-as-code boundary and enterprise growth path.
availability:
current: A2
target: A5
confidence: low
rationale: Policy registry and evaluation logic exist in repo; service packaging evolving.
external_evidence:
completeness:
level: C2
name: Partial
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- policy-as-code intent documented
broken_expectations:
- not yet indexed from flex-auth native registry
out_of_scope_expectations:
- identity proofing
reliability:
level: R1
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- early implementation phase
discovery:
intent: >
Provide inspectable authorization decisions between verified identity and
protected resources using policy-as-code.
includes:
- policy evaluation
- authorization registry
- decision explainability
excludes:
- identity issuance
- authentication protocols
use_cases: []
availability:
current_level: A2
target_level: A5
current_artifacts:
- flex-auth/
consumption_modes:
- source module
relations:
depends_on:
- capability.identity.subject-resolution
related_to:
- capability.feature-control.evaluate
consumer_guidance:
recommended_for:
- planning authorization layer between identity and resources
not_recommended_for:
- feature visibility toggles without policy intent
known_limitations:
- maturity evidence is registry-external today
---
# Authorization Policy Evaluation
Policy evaluation from flex-auth sits between identity resolution and protected
systems.

View File

@@ -1,138 +0,0 @@
---
id: capability.feature-control.evaluate
name: Feature Availability Evaluation
summary: Evaluate whether a feature is active, hidden, disabled, or unavailable for a subject in context.
owner: feature-control
status: draft
domain: helix_forge
tags:
- feature-control
- evaluation
- sdk
maturity:
discovery:
current: D5
target: D7
confidence: medium
rationale: >
Concrete use cases and research references are documented in the maturity
standard example and feature-control domain work.
availability:
current: A4
target: A6
confidence: medium
rationale: >
SDK and service API artifacts exist in the feature-control repository.
Managed platform operation is the natural target for multi-tenant reuse.
external_evidence:
completeness:
level: C3
name: Functional Core
confidence: medium
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- tenant-level feature evaluation
- user-level feature evaluation
- machine-readable decision result
broken_expectations:
- no agent-specific rule simulation
- no bulk import/export of rules
out_of_scope_expectations:
- billing entitlement ownership
- authorization policy enforcement
reliability:
level: R3
name: Usable
confidence: medium
basis: consumer_quality_signals
known_reliability_risks:
- unclear timeout behavior under heavy load
- limited diagnostics for complex tenant rule conflicts
discovery:
intent: >
Support controlled feature availability across installations, tenants,
domains, groups, users, and agents.
includes:
- feature decision evaluation
- context-aware targeting
- explainable decision result
excludes:
- user authorization
- billing entitlement ownership
- UI rendering
assumptions:
- subject and tenant context can be resolved by adjacent capabilities
use_cases:
- ucc.feature-control.tenant-toggle
- ucc.feature-control.agent-disable
- ucc.feature-control.domain-rollout
research_memos:
- specs/CapabilityMaturityStandard.md
availability:
current_level: A4
target_level: A6
current_artifacts:
- feature-control/packages/feature-control-sdk
- feature-control/services/feature-control-api
target_artifacts:
- feature-control/charts/feature-control
- feature-control/platform/feature-control-service
consumption_modes:
- SDK
- service API
- managed platform service
relations:
depends_on:
- capability.identity.vocabulary-canonicalize
supports:
- capability.registry.register
related_to:
- capability.feature-control.rollout
- capability.feature-control.visibility
evidence:
documentation:
- specs/CapabilityMaturityStandard.md
tests: []
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- application integration through SDK or service API
- tenant-aware feature gating in helix_forge products
not_recommended_for:
- authorization decisions
- billing entitlement ownership
- assuming agent-specific simulation without checking current scope
known_limitations:
- bulk rule management is not yet covered
- agent-specific simulation remains a known gap
---
# Feature Availability Evaluation
## Overview
This capability evaluates whether a feature should be available for a subject in
a given context. It is the primary implementation-ready example in the sample
registry and demonstrates a D5/A4/C3/R3 vector.
## Current reuse mode
Consumers can integrate through SDK or service API artifacts in the
feature-control repository. This is implementation reuse (A4), not just planning
metadata.
## Comparison notes
Compared with `capability.registry.register`, this entry is far stronger on
availability and external evidence. Compared with
`capability.identity.vocabulary-canonicalize`, it is stronger on delivery mode
and weaker on cross-domain generalization.

View File

@@ -1,111 +0,0 @@
---
id: capability.feature-control.rollout
name: Feature Rollout Control
summary: Gradually expose features to subjects across tenants, domains, groups, or cohorts using rollout rules and staged availability.
owner: feature-control
status: draft
domain: helix_forge
tags:
- feature-control
- rollout
- planning
maturity:
discovery:
current: D4
target: D6
confidence: medium
rationale: >
Rollout is a distinct bounded behavior from single-point evaluation, with
research references in the feature-control domain and maturity standard.
availability:
current: A2
target: A4
confidence: low
rationale: >
Rollout logic may exist in source modules but is not yet consistently
exposed as a standalone SDK or API surface distinct from evaluate.
external_evidence:
completeness:
level: C2
name: Partial
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- rollout concepts documented adjacent to feature evaluation
broken_expectations:
- no dedicated rollout artifact called out separately from evaluate
- percentage and cohort rollout variants not indexed independently
out_of_scope_expectations:
- billing-driven entitlements
reliability:
level: R1
name: Fragile
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- rollout behavior may be conflated with evaluate in consumer mental models
discovery:
intent: >
Control how features become available over time and across cohorts without
conflating rollout policy with authorization or billing.
includes:
- staged rollout rules
- cohort and context targeting for rollout
- explainable rollout state
excludes:
- one-time feature evaluation only
- authorization decisions
- billing entitlements
assumptions:
- feature evaluation capability exists for final availability decisions
use_cases:
- ucc.feature-control.domain-rollout
research_memos:
- specs/CapabilityMaturityStandard.md
availability:
current_level: A2
target_level: A4
current_artifacts:
- feature-control/packages/feature-control-sdk
target_artifacts:
- feature-control/services/feature-control-api
consumption_modes:
- source module
- SDK
relations:
depends_on:
- capability.feature-control.evaluate
supports: []
related_to:
- capability.feature-control.visibility
evidence:
documentation:
- specs/CapabilityMaturityStandard.md
tests: []
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- planning staged feature exposure separate from binary evaluation
not_recommended_for:
- simple on/off evaluation without rollout semantics
- entitlement or billing ownership
known_limitations:
- distinguish carefully from capability.feature-control.evaluate
---
# Feature Rollout Control
## Overview
Rollout governs how availability changes over time and across cohorts. It
complements evaluation, which answers whether a feature is available for a
subject in a context right now.

View File

@@ -1,77 +0,0 @@
---
id: capability.feature-control.visibility
name: Feature Visibility Control
summary: Control whether features are visible or hidden for subjects without changing underlying entitlement or authorization.
owner: feature-control
status: draft
domain: helix_forge
tags: [feature-control, visibility]
maturity:
discovery:
current: D4
target: D5
confidence: medium
rationale: Bounded as distinct from evaluation and rollout in feature-control domain.
availability:
current: A2
target: A4
confidence: low
rationale: May share SDK artifacts with evaluate but is not separately exposed as API.
external_evidence:
completeness:
level: C2
name: Partial
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- visibility distinguished from evaluation in registry model
broken_expectations:
- no standalone visibility API documented separately
out_of_scope_expectations:
- authorization policy decisions
reliability:
level: R1
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- easily conflated with evaluate capability
discovery:
intent: Govern feature visibility separately from availability evaluation and rollout staging.
includes:
- hide/show feature UI or capability surfaces
- visibility rules per subject context
excludes:
- entitlement ownership
- rollout percentage control
use_cases: []
availability:
current_level: A2
target_level: A4
current_artifacts:
- feature-control/packages/feature-control-sdk
consumption_modes:
- source module
relations:
depends_on:
- capability.feature-control.evaluate
related_to:
- capability.feature-control.rollout
consumer_guidance:
recommended_for:
- planning visibility behavior separate from on/off evaluation
not_recommended_for:
- authorization or billing gating
known_limitations:
- implementation may be bundled with evaluate SDK today
---
# Feature Visibility Control
Visibility governs whether a feature surface appears, distinct from whether the
feature is enabled for a subject.

View File

@@ -1,115 +0,0 @@
---
id: capability.identity.subject-resolution
name: Identity Subject Resolution
summary: Resolve who or what is acting in a context by mapping principals, accounts, actors, and identifiers to a stable subject model.
owner: identity-canon
status: draft
domain: helix_forge
tags:
- identity
- subject
- architecture
maturity:
discovery:
current: D3
target: D5
confidence: medium
rationale: >
Subject/principal terminology is explored in identity-canon conflict maps
and conceptual model, but dedicated use-case grounding is incomplete.
availability:
current: A0
target: A4
confidence: low
rationale: >
Canon and research artifacts exist; no standalone resolver service or SDK
is registered yet.
external_evidence:
completeness:
level: C1
name: Fragmentary
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- overloaded subject and principal terms are mapped as candidates
broken_expectations:
- no runtime resolver artifact
- canonical subject model not finalized across all actor types
out_of_scope_expectations:
- authentication protocol implementation
- credential storage
reliability:
level: R0
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- draft terminology may change during source-note backfill
discovery:
intent: >
Give planners and implementers a consistent subject concept for authorization,
feature control, tenancy, and agent workflows without collapsing product-specific
identity models.
includes:
- subject vs principal vs account distinctions
- actor type modeling
- identifier resolution concepts
excludes:
- authentication execution
- credential issuance
- directory provisioning
assumptions:
- vocabulary canonicalization supports but does not replace subject resolution
use_cases:
- UC-RS-004
research_memos:
- identity-canon/terminology/TerminologyConflictMap.md
- identity-canon/model/ConceptualModel.md
availability:
current_level: A0
target_level: A4
current_artifacts:
- identity-canon/model/ConceptualModel.md
- identity-canon/canon/CanonicalGlossary.md
target_artifacts:
- identity-canon/packages/subject-resolution-sdk
consumption_modes:
- informational
relations:
depends_on:
- capability.identity.vocabulary-canonicalize
supports:
- capability.feature-control.evaluate
- capability.statehub.workstream-coordinate
related_to: []
evidence:
documentation:
- identity-canon/canon/CanonicalGlossary.md
- identity-canon/scenarios/ScenarioTests.md
tests: []
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- architecture planning where subject/principal/account terms overlap
not_recommended_for:
- runtime authentication or token validation
- treating draft canon as finalized resolver behavior
known_limitations:
- resolver artifacts are not yet available
---
# Identity Subject Resolution
## Overview
Subject resolution defines how actors and identifiers map to a stable subject
concept for downstream capabilities such as feature evaluation and coordination.
Today this capability is planning-heavy (D3/A0).

View File

@@ -1,136 +0,0 @@
---
id: capability.identity.vocabulary-canonicalize
name: Identity Vocabulary Canonicalization
summary: Define and maintain an implementation-neutral vocabulary for identity-related concepts across overlapping domains.
owner: identity-canon
status: draft
domain: helix_forge
tags:
- identity
- terminology
- research
maturity:
discovery:
current: D4
target: D6
confidence: medium
rationale: >
identity-canon has researched overlapping terminology across IAM,
directory, federation, and authorization domains, but use-case saturation
is not yet demonstrated.
availability:
current: A0
target: A2
confidence: medium
rationale: >
The capability is available as research and canon documentation only.
Future source modules or libraries could raise availability to A2.
external_evidence:
completeness:
level: C2
name: Partial
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- draft canonical glossary exists
- terminology conflict map exists
- conceptual model and scenario tests exist
broken_expectations:
- individual source notes are not fully backfilled
- many mappings remain candidate rather than finalized
out_of_scope_expectations:
- operating identity providers
- provisioning or authorization engines
reliability:
level: R0
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- draft canon terms may change as source evidence is backfilled
discovery:
intent: >
Provide a reusable planning primitive for identity vocabulary so architects
and agents can compare overlapping terms consistently without collapsing
product-specific meanings into one ambiguous label.
includes:
- canonical glossary maintenance
- terminology conflict mapping
- conceptual model and scenario tests
- research corpus indexing
excludes:
- identity provider implementation
- account lifecycle services
- authorization policy enforcement
assumptions:
- external product mappings remain separate from canonical definitions
use_cases:
- UC-RS-004
- UC-RS-006
research_memos:
- identity-canon/ResearchProposal.md
- identity-canon/canon/CanonicalGlossary.md
availability:
current_level: A0
target_level: A2
current_artifacts:
- identity-canon/canon/CanonicalGlossary.md
- identity-canon/terminology/TerminologyConflictMap.md
- identity-canon/model/ConceptualModel.md
target_artifacts:
- identity-canon/packages/identity-vocabulary
consumption_modes:
- informational
- markdown research artifacts
relations:
depends_on: []
supports:
- capability.feature-control.evaluate
- capability.registry.register
related_to:
- capability.identity.subject-resolution
evidence:
documentation:
- identity-canon/INTENT.md
- identity-canon/canon/CanonicalGlossary.md
tests: []
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- architecture and planning conversations involving overloaded identity terms
- comparing IAM, directory, and authorization vocabulary without forcing one product model
not_recommended_for:
- runtime identity resolution
- assuming draft canon entries are finalized standards
known_limitations:
- source-note backfill is incomplete
- mappings may remain candidate until evidence review completes
---
# Identity Vocabulary Canonicalization
## Overview
This capability makes identity vocabulary reusable for planning across adjacent
domains. It is intentionally research-heavy and informational, illustrating a
D4/A0/C2/R0 vector that contrasts with implementation-ready entries.
## Current reuse mode
Consumers read canon, terminology, and model artifacts in the identity-canon
repository. The value is planning reuse through shared vocabulary, not runtime
integration.
## Relation to adjacent capabilities
Feature-control evaluation depends on consistent subject and tenant concepts.
This capability supports that planning layer without providing runtime identity
services itself.

View File

@@ -1,91 +0,0 @@
---
id: capability.statehub.progress-log
name: Work Progress Logging
summary: Record progress events, decisions, and session notes against workstreams and tasks in State Hub.
owner: state-hub
status: draft
domain: helix_forge
tags: [state-hub, progress, coordination]
maturity:
discovery:
current: D4
target: D5
confidence: medium
rationale: Progress API and agent session protocol are documented in state-hub AGENTS.md.
availability:
current: A4
target: A6
confidence: medium
rationale: Available via State Hub HTTP POST /progress/ endpoint.
external_evidence:
completeness:
level: C3
name: Functional Core
confidence: medium
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- progress events attach to workstreams
- agents can log session summaries
broken_expectations: []
out_of_scope_expectations:
- replacing git commit history
reliability:
level: R3
name: Usable
confidence: medium
basis: consumer_quality_signals
known_reliability_risks:
- depends on hub availability and tunnel health for remote agents
evidence:
satisfied_signals:
- reuse-surface AGENTS.md session-close protocol cites POST /progress/
- cross-repo agents log progress with workstream_id linkage
discovery:
intent: Provide auditable progress memory for cross-repo agent and operator work.
includes:
- progress event creation
- workstream and task linkage
- author attribution
excludes:
- canonical workplan storage
use_cases: []
availability:
current_level: A4
target_level: A6
current_artifacts:
- state-hub/api/
consumption_modes:
- service API
relations:
depends_on:
- capability.statehub.workstream-coordinate
supports: []
related_to:
- capability.statehub.workstream-coordinate
evidence:
documentation:
- AGENTS.md
consumer_feedback:
- >
reuse-surface agents (REUSE-WP-0012): session-close progress posts to State
Hub succeeded for workstream fb0b6067 during federation workplan work.
consumer_guidance:
recommended_for:
- closing agent sessions with hub progress notes
not_recommended_for:
- authoritative task status (use workplan files + fix-consistency)
known_limitations:
- hub must be running locally or via tunnel
---
# Work Progress Logging
Progress logging complements file-backed workplans with live session memory in
State Hub.

View File

@@ -1,117 +0,0 @@
---
id: capability.statehub.workstream-coordinate
name: Workstream And Task Coordination
summary: Track active workstreams, tasks, progress, and consistency across domain repositories through a local-first coordination service.
owner: state-hub
status: draft
domain: helix_forge
tags:
- state-hub
- coordination
- workplans
maturity:
discovery:
current: D4
target: D5
confidence: medium
rationale: >
State Hub intent, scope, and ADR-001 workplan conventions are documented;
concrete agent workflows are still being standardized across repos.
availability:
current: A4
target: A6
confidence: medium
rationale: >
Consumers integrate through the State Hub HTTP API and custodian scripts.
Managed platform operation is the natural target for multi-repo agents.
external_evidence:
completeness:
level: C3
name: Functional Core
confidence: medium
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- workstream and task tracking via HTTP API
- workplan file to database consistency sync
- progress event logging
broken_expectations:
- no native MCP server for all agent environments
out_of_scope_expectations:
- replacing git-backed workplan canon
- identity authority
reliability:
level: R2
name: Tolerable
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- depends on local hub availability and operator maintenance
discovery:
intent: >
Give agents and operators a live, queryable memory of work across domains
without replacing file-backed workplans and governance canon.
includes:
- workstream and task indexing
- progress and decision events
- repo consistency synchronization
- inbox and human-review flags
excludes:
- canon ownership
- task factory for all work origins
- identity authority
assumptions:
- workplans remain authoritative in git for ADR-001 repos
use_cases:
- UC-RS-013
research_memos:
- state-hub/INTENT.md
availability:
current_level: A4
target_level: A6
current_artifacts:
- state-hub/api/
- state-hub/scripts/consistency_check.py
target_artifacts:
- state-hub/platform/state-hub-service
consumption_modes:
- service API
- HTTP REST
relations:
depends_on: []
supports:
- capability.registry.register
related_to:
- capability.statehub.progress-log
evidence:
documentation:
- state-hub/INTENT.md
- state-hub/AGENTS.md
tests: []
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- cross-repo agent orientation and task status sync
- logging progress after workplan changes
not_recommended_for:
- storing canonical requirements or architecture canon
- assuming hub state overrides git workplan files
known_limitations:
- requires running State Hub locally or via tunnel
---
# Workstream And Task Coordination
## Overview
State Hub provides live coordination for helix_forge repositories while
workplans remain file-backed. This entry represents the service/API consumption
mode for cross-repo agent work.

View File

@@ -1,103 +0,0 @@
---
id: capability.wiki.adapter-contract
name: Capability-Aware Shard Adapter Contract
summary: A versioned backend interface where each binding declares a verified capability profile (positions on capability spectra), so federation ops degrade by capability.
owner: shard-wiki
status: draft
domain: helix_forge
tags: [wiki, adapter, capability, contract, conformance, shard-wiki]
maturity:
discovery:
current: D5
target: D6
confidence: high
rationale: >
Fifteen capability spectra with an orthogonal core + implication rules, plus
a normative contract spec (TSD Section A); derived from a ~23-system synthesis.
availability:
current: A2
target: A5
confidence: medium
rationale: >
AdapterContract + a read/write FolderAdapter + a conformance suite that
verifies declared profile == observed behaviour exist as a source module.
external_evidence:
completeness:
level: C2
name: Partial
confidence: medium
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- versioned interface with declared, conformance-verified capability profiles
- one concrete adapter (file-store) passes the conformance suite
broken_expectations:
- only one substrate implemented (git-IS-store, REST, CRDT adapters planned)
out_of_scope_expectations:
- hosting backends
reliability:
level: R1
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- single adapter implemented so far
discovery:
intent: >
Mediate heterogeneity at one narrow waist: a backend participates by implementing a
versioned interface and declaring a verified position on each capability spectrum.
includes:
- capability profile as data (orthogonal-core spectra + implied positions)
- operation verbs (read/write/diff/merge/notify/.../derive-projection/execute)
- a conformance suite (profiles verified, not self-asserted)
excludes:
- assuming uniform backend capabilities
use_cases:
- "shard-wiki UseCaseCatalog UC-34..UC-43, UC-50, UC-57, UC-60..UC-69 (shard attachment & adapter binding)"
availability:
current_level: A2
target_level: A5
current_artifacts:
- "shard-wiki/src/shard_wiki/adapters/"
consumption_modes:
- source module
relations:
depends_on:
- capability.wiki.page-model
supports:
- capability.wiki.shard-orchestration
evidence:
documentation:
- "shard-wiki/spec/TechnicalSpecificationDocument.md (Section A)"
- "shard-wiki/spec/CoreArchitectureBlueprint.md (Section 6)"
tests:
- "shard-wiki/tests/test_folder_adapter.py"
- "shard-wiki/tests/test_conformance.py"
consumer_guidance:
recommended_for:
- exposing any page store as a capability-described, conformance-checked shard
not_recommended_for:
- backends that cannot honestly describe their capabilities
known_limitations:
- reference implementation covers the file-store substrate only so far
---
# Capability-Aware Shard Adapter Contract
The bottom narrow waist of shard-wiki: a versioned interface plus a **verified** capability
profile per binding. Core logic is written once against capabilities (not per-backend), and
the conformance suite rejects profiles whose declared abilities don't match observed behaviour.
## Assessment notes
### Discovery
Fifteen spectra reduced to an orthogonal core with implication rules (CoreArchitectureBlueprint
Section 6.5); normative in TSD Section A.
### Availability
`adapters/` ships the contract, a folder adapter, and `assert_conformant`.

View File

@@ -1,103 +0,0 @@
---
id: capability.wiki.coordination-journal
name: Event-Sourced Coordination Journal
summary: An append-only, totally-ordered-per-space decision log (overlays, bindings, aliases, merges, forks) whose current state is a derived fold; git-addressable history.
owner: shard-wiki
status: draft
domain: helix_forge
tags: [wiki, event-sourcing, coordination, git, journal, shard-wiki]
maturity:
discovery:
current: D5
target: D6
confidence: high
rationale: >
Keystone resolved across two architecture reviews: coordination-canonical state
as an append-only decision log with a per-space append authority; current state
is a derived fold (derived = f(log)).
availability:
current: A2
target: A4
confidence: medium
rationale: >
In-memory DecisionLog + fold work as a source module; the git-backed store with a
per-space lease (the production backing) is planned.
external_evidence:
completeness:
level: C2
name: Partial
confidence: medium
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- append-only, totally-ordered-per-space log with read-your-writes
- derived fold to aliases + transitively-merged equivalence groups
broken_expectations:
- git-backed storage and per-space lease/append-authority not yet implemented
out_of_scope_expectations:
- general-purpose event bus
reliability:
level: R1
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- in-memory backing only; cross-process durability pending
discovery:
intent: >
Make coordination-canonical decisions durable and git-addressable as events, with the
queryable current state always recomputable by replay.
includes:
- append-only decision log, totally ordered per information space
- derived fold to current coordination state (aliases, equivalence groups, overlays)
- per-space append authority (concurrency model)
excludes:
- storing derived/disposable union state
use_cases:
- "shard-wiki UseCaseCatalog UC-29, UC-33 (history, attribution, coordination journal)"
availability:
current_level: A2
target_level: A4
current_artifacts:
- "shard-wiki/src/shard_wiki/coordination/decision_log.py"
target_artifacts:
- git-backed log store with per-space lease
consumption_modes:
- source module
relations:
supports:
- capability.wiki.shard-orchestration
- capability.wiki.overlay
evidence:
documentation:
- "shard-wiki/spec/CoreArchitectureBlueprint.md (Section 8.1)"
tests:
- "shard-wiki/tests/test_decision_log.py"
consumer_guidance:
recommended_for:
- durable, replayable, git-addressable coordination state for a federated space
not_recommended_for:
- high-frequency general event streaming
known_limitations:
- production git backing + lease are still on the roadmap (SHARD-WP-0009)
---
# Event-Sourced Coordination Journal
The keystone: coordination-canonical state (overlays, equivalence bindings, aliases, merges,
forks) is an append-only **decision log**, totally ordered per information space; the queryable
current state is a derived **fold** of the log (`derived = f(log)`). The log is git-addressable,
giving history/patch/review/backup for coordination decisions for free.
## Assessment notes
### Discovery
Resolved across the round-1/round-2 architecture reviews (CoreArchitectureBlueprint Section 8.1).
### Availability
`decision_log.py` ships an in-memory, totally-ordered log + fold; git+lease backing is planned.

View File

@@ -1,87 +0,0 @@
---
id: capability.wiki.derived-views
name: Wiki Derived Views
summary: Recomputable views over a wiki union — BackLinks, RecentChanges, AllPages, SiteMap, and (delegate-or-derive) Search — carrying provenance.
owner: shard-wiki
status: draft
domain: helix_forge
tags: [wiki, derived-views, backlinks, recentchanges, search, shard-wiki]
maturity:
discovery:
current: D3
target: D5
confidence: medium
rationale: >
Core-vs-adapter classification and behaviours are decided (FederationRequirements ADR-03);
implementation is planned (SHARD-WP-0010), not built.
availability:
current: A0
target: A4
confidence: low
rationale: >
Designed; no implementation yet. Informational/planning reuse only today.
external_evidence:
completeness:
level: C0
name: Absent
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations: []
broken_expectations:
- no derived view is implemented yet
out_of_scope_expectations:
- presentation / rendering of views
reliability:
level: R0
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- planning-stage
discovery:
intent: >
Provide recomputable, provenance-carrying views over the union (link graph, change feed,
enumeration, search) without introducing canonical state.
includes:
- BackLinks (link graph), RecentChanges (journal + shard signals), AllPages, SiteMap
- Search as delegate-to-native-or-derive-index
excludes:
- view presentation / UI
use_cases:
- "shard-wiki UseCaseCatalog UC-17..UC-21, UC-63"
availability:
current_level: A0
target_level: A4
current_artifacts:
- "shard-wiki/workplans/SHARD-WP-0010-derived-views.md"
consumption_modes:
- informational
relations:
depends_on:
- capability.wiki.shard-orchestration
- capability.wiki.page-model
related_to:
- capability.wiki.engine-typed-extensions
evidence:
documentation:
- "shard-wiki/spec/FederationRequirements.md (ADR-03)"
consumer_guidance:
recommended_for:
- planning derived navigation/discovery over a federated wiki union
not_recommended_for:
- implementation reuse today (planning-stage)
known_limitations:
- not implemented; Search ranking policy undecided
---
# Wiki Derived Views
Recomputable views over the union (BackLinks, RecentChanges, AllPages, SiteMap, Search). All
are derived/disposable (no canonical state) and carry provenance; Search is delegate-to-native
where a shard's query capability allows, else a derived index. Planned in SHARD-WP-0010.

View File

@@ -1,115 +0,0 @@
---
id: capability.wiki.engine-typed-extensions
name: Wiki Engine with Typed Extensions
summary: A small-core wiki engine realizing a stringent typed-extension framework that addresses all wiki use cases and lets each shard activate only the features it needs.
owner: shard-wiki
status: draft
domain: helix_forge
tags: [wiki, engine, typed-extensions, feature-activation, shard-wiki]
maturity:
discovery:
current: D3
target: D5
confidence: medium
rationale: >
Architecture authored (shard-wiki/spec/WikiEngineCoreArchitecture.md): small page-store
kernel + typed-extension framework, per-shard activation, engine-as-canonical-mode-shard,
and a conflict-mediation realization are explored. Detailed extension SDK/ABI and the API
protocol remain (so D3 Explored, not yet D4/D5).
availability:
current: A0
target: A4
confidence: low
rationale: >
Planned. No engine kernel or extensions exist yet; informational/planning reuse only.
external_evidence:
completeness:
level: C0
name: Absent
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations: []
broken_expectations:
- engine core and typed-extension mechanism not yet designed in detail
out_of_scope_expectations:
- replacing other wiki engines or mandating one implementation
reliability:
level: R0
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- planning-stage capability
discovery:
intent: >
Provide shard-wiki's reference first-party shard backend: a small core + a stringent
typed-extension framework covering all collected use cases, mediating conflicting
requirements into an integrated whole, with per-shard activation (only what you need).
includes:
- a minimal engine kernel (page lifecycle, storage via the adapter contract, the typing mechanism)
- typed extensions that declare contracts and compose
- per-shard feature activation
excludes:
- replacing or mandating other wiki engines (it is one shard type among many)
- a single canonical implementation for all wikis
use_cases:
- "shard-wiki UseCaseCatalog UC-08..UC-25 and the full catalog (the engine must cover all)"
availability:
current_level: A0
target_level: A4
current_artifacts:
- "shard-wiki/workplans/SHARD-WP-0013-wiki-engine-prep.md"
- "shard-wiki/spec/WikiEngineCoreArchitecture.md"
consumption_modes:
- informational
relations:
depends_on:
- capability.wiki.adapter-contract
- capability.wiki.page-model
related_to:
- capability.feature-control.evaluate
- capability.authorization.policy-evaluate
evidence:
documentation:
- "shard-wiki/workplans/SHARD-WP-0013-wiki-engine-prep.md"
consumer_guidance:
recommended_for:
- planning a composable, feature-activatable native wiki engine
not_recommended_for:
- implementation reuse today (planning-stage)
known_limitations:
- architecture authored; extension SDK/ABI + API protocol still to design; not yet built
promotion_history:
- date: "2026-06-15"
dimension: discovery
from: D2
to: D3
rationale: WikiEngineCoreArchitecture.md authored (kernel + typed-extension framework explored); INTENT amendment ratified.
author: shard-wiki
---
# Wiki Engine with Typed Extensions
shard-wiki's planned reference first-party shard backend — a *canonical-mode shard* it
implements natively: a small core plus a stringent typed-extension framework addressing all
collected use cases, mediating conflicting requirements into a consistent whole, with per-shard
activation (activate only what you need). It is one shard type among many — not a replacement
for other engines. Per-shard activation is a candidate consumer of
`capability.feature-control.evaluate`.
## Assessment notes
### Discovery
Architecture authored: `shard-wiki/spec/WikiEngineCoreArchitecture.md` (small kernel +
typed-extension framework; engine = canonical-mode shard). INTENT amendment ratified
(2026-06-15, decision 84ffdb48). Extension SDK/ABI + API protocol are the next deliverables.
### Availability
Planning-stage; informational reuse only.

View File

@@ -1,97 +0,0 @@
---
id: capability.wiki.federation-models
name: Selectable Federation-Model Taxonomy
summary: Federation as a plural, composable coordination axis (fork+journal, VCS-replication+ping, query-time graph-join, feed, activity-streams, engine-mirror) selected per space.
owner: shard-wiki
status: draft
domain: helix_forge
tags: [wiki, federation, taxonomy, composable, shard-wiki]
maturity:
discovery:
current: D4
target: D6
confidence: high
rationale: >
A six-model taxonomy distilled from a ~23-system synthesis, each model anchored in a
real system, with capability prerequisites and per-space/per-shard composition rules.
availability:
current: A0
target: A4
confidence: low
rationale: >
Designed and specified (FederationArchitecture T17) but not implemented; informational
reuse only today.
external_evidence:
completeness:
level: C1
name: Sparse
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- the model taxonomy and selection/composition rules are documented
broken_expectations:
- no federation transport is implemented yet
out_of_scope_expectations:
- mandating a single federation mechanism
reliability:
level: R0
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- design-stage; no runtime evidence
discovery:
intent: >
Treat federation as selectable and composable rather than one mechanism, so each space
picks fork+journal, VCS-replication, query-join, feed, activity-streams, or engine-mirror.
includes:
- the six federation models + their capability floors
- per-space selection and per-shard composition
excludes:
- imposing one homogeneous federation network
use_cases:
- "shard-wiki UseCaseCatalog UC-26, UC-31, UC-33, UC-71, UC-72, UC-74, UC-79"
availability:
current_level: A0
target_level: A4
current_artifacts:
- "shard-wiki/spec/FederationArchitecture.md (T17)"
consumption_modes:
- informational
relations:
depends_on:
- capability.wiki.shard-orchestration
- capability.wiki.coordination-journal
evidence:
documentation:
- "shard-wiki/spec/FederationArchitecture.md"
- "shard-wiki/research/260614-shard-spectrum-synthesis/findings.md"
consumer_guidance:
recommended_for:
- planning a federation strategy that mixes models per source
not_recommended_for:
- implementation reuse today (design-stage)
known_limitations:
- no transport implemented; informational planning reuse only
---
# Selectable Federation-Model Taxonomy
Federation is plural and composable: fork+journal (Federated Wiki), VCS-replication+ping
(ikiwiki), query-time graph-join (Wikibase SERVICE), feed aggregation, activity streams
(ActivityPub), and engine-mirror (Wiki.js). A space selects a model and composes per shard;
the default is fork+journal over git. Design-stage capability — strong for planning reuse.
## Assessment notes
### Discovery
FederationArchitecture T17, distilled from the shard-spectrum synthesis (v3).
### Availability
Specified, not implemented — informational reuse only.

View File

@@ -1,102 +0,0 @@
---
id: capability.wiki.overlay
name: Overlay-Before-Mutation Write Path
summary: Non-destructive edits (draft -> patch -> apply-under-drift) that let read-only, rate-limited, or lossy backends be edited safely without silent remote mutation.
owner: shard-wiki
status: draft
domain: helix_forge
tags: [wiki, overlay, patch, write-path, conflict, shard-wiki]
maturity:
discovery:
current: D5
target: D6
confidence: high
rationale: >
Overlay lifecycle and apply-under-drift semantics are specified (ADR-05, blueprint
Section 8.6) and implemented as a single principled write path.
availability:
current: A2
target: A4
confidence: medium
rationale: >
OverlayEngine (draft/patch/apply), writable adapter, and InformationSpace.edit
exist as a source module; three-way merge is not (refuse-on-drift only).
external_evidence:
completeness:
level: C2
name: Partial
confidence: medium
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- draft -> patch -> apply with fast-forward / refuse-on-drift / keep-draft outcomes
- no silent remote mutation; overlay_state surfaced in provenance
broken_expectations:
- three-way / auto merge not implemented (refuse-on-conflict only)
out_of_scope_expectations:
- federation propagation of applied overlays
reliability:
level: R1
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- early implementation; conflict handling is detect-and-refuse only
discovery:
intent: >
Make any sub-write-through backend editable safely: an edit is an overlay first, applied
only on explicit intent and only when the source has not drifted.
includes:
- overlay drafts recorded as coordination-canonical events
- patch rendering (unified diff)
- apply-under-drift (fast-forward / refuse / keep-draft)
excludes:
- destructive write without drift check
use_cases:
- "shard-wiki UseCaseCatalog UC-04, UC-26, UC-29 (remix primitives, overlay)"
availability:
current_level: A2
target_level: A4
current_artifacts:
- "shard-wiki/src/shard_wiki/coordination/overlay.py"
- "shard-wiki/src/shard_wiki/coordination/patch.py"
consumption_modes:
- source module
relations:
depends_on:
- capability.wiki.coordination-journal
- capability.wiki.adapter-contract
evidence:
documentation:
- "shard-wiki/spec/FederationRequirements.md (ADR-05)"
- "shard-wiki/spec/CoreArchitectureBlueprint.md (Section 8.2, 8.6)"
tests:
- "shard-wiki/tests/test_apply.py"
- "shard-wiki/tests/test_write_path_integration.py"
consumer_guidance:
recommended_for:
- safe editing over read-only / rate-limited / lossy backends
not_recommended_for:
- workflows needing automatic conflict resolution today
known_limitations:
- merge is detect-and-refuse; three-way merge is future work
---
# Overlay-Before-Mutation Write Path
One principled write path: every edit drafts an overlay (a coordination-canonical event),
renders as a patch, and applies under drift checks — fast-forwarding a writable target,
keeping a local draft on a read-only target, and refusing (never clobbering) on external drift.
## Assessment notes
### Discovery
Specified in FederationRequirements ADR-05 and CoreArchitectureBlueprint Section 8.2/8.6.
### Availability
`overlay.py` + `patch.py` + `InformationSpace.edit` ship the path; built in SHARD-WP-0008.

View File

@@ -1,104 +0,0 @@
---
id: capability.wiki.page-model
name: Backend-Neutral Wiki Page Model
summary: A Markdown-first but stretchable page model with stable identity separate from placement and layered provenance, spanning prose to typed-graph and computational shapes.
owner: shard-wiki
status: draft
domain: helix_forge
tags: [wiki, page-model, identity, provenance, markdown, shard-wiki]
maturity:
discovery:
current: D5
target: D6
confidence: high
rationale: >
Page shapes (prose, typed records, typed-graph, inline-embedded, non-Markdown,
and four computational shapes) plus identity != placement and layered provenance
are specified and grounded in the dive research.
availability:
current: A2
target: A5
confidence: medium
rationale: >
Identity/Placement/Span/Page and layered ProvenanceEnvelope exist as a source
module; richer shapes (typed-graph, notebook) are modeled but not all built.
external_evidence:
completeness:
level: C2
name: Partial
confidence: medium
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- stable identity distinct from placement and from content fingerprint
- layered (effective-vs-own) provenance with near-zero per-span cost
broken_expectations:
- non-prose shapes (typed-graph, notebook, inline-embedded) not fully realized
out_of_scope_expectations:
- rendering / presentation
reliability:
level: R1
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- prose shape is the only exercised path so far
discovery:
intent: >
One backend-neutral lingua franca every consumer sees; every shape reduces to
(content|source, structure, provenance envelope, optional derivation rule).
includes:
- page identity (stable handle) vs placement (N paths/shards) vs equivalence (fingerprint)
- layered provenance envelope (page + span deltas)
- page-shape taxonomy incl. computational shapes
excludes:
- deriving identity from content (a fingerprint identifies a version, not a page)
use_cases:
- "shard-wiki UseCaseCatalog UC-34, UC-39, UC-44..UC-49, UC-55, UC-73, UC-83, UC-84"
availability:
current_level: A2
target_level: A5
current_artifacts:
- "shard-wiki/src/shard_wiki/model/"
- "shard-wiki/src/shard_wiki/provenance/"
consumption_modes:
- source module
relations:
supports:
- capability.wiki.adapter-contract
- capability.wiki.shard-orchestration
evidence:
documentation:
- "shard-wiki/spec/CoreArchitectureBlueprint.md (Section 7)"
- "shard-wiki/spec/FederationRequirements.md (ADR-02, ADR-04)"
tests:
- "shard-wiki/tests/test_model.py"
- "shard-wiki/tests/test_provenance.py"
consumer_guidance:
recommended_for:
- a portable, provenance-carrying representation of wiki pages across backends
not_recommended_for:
- cases needing a single canonical path per page (use identity, not path)
known_limitations:
- non-prose shapes specified ahead of implementation
---
# Backend-Neutral Wiki Page Model
The top narrow waist: a Markdown-first model that stretches to typed records, typed-graph
statements, inline-embedded objects, non-Markdown assets, and computational shapes. Identity
is a stable handle; placement and equivalence are separate mechanisms; provenance is layered
(effective = page envelope + span delta).
## Assessment notes
### Discovery
Specified in CoreArchitectureBlueprint Section 7 and FederationRequirements ADR-02/04.
### Availability
`model/` + `provenance/` ship the prose path and the layered envelope today.

View File

@@ -1,114 +0,0 @@
---
id: capability.wiki.shard-orchestration
name: Wiki Shard Orchestration
summary: Present a union of pages across heterogeneous wiki-shaped shards while preserving each shard's provenance, capabilities, and history.
owner: shard-wiki
status: draft
domain: helix_forge
tags: [wiki, federation, orchestration, union, shard-wiki]
maturity:
discovery:
current: D5
target: D6
confidence: high
rationale: >
Grounded in 84 documented use cases and a twice-reviewed whole-system
architecture (CoreArchitectureBlueprint) derived from ~23 prior-art systems.
availability:
current: A2
target: A5
confidence: medium
rationale: >
InformationSpace orchestrator (attach -> resolve -> read, chorus on
ambiguity) works as a Python source module; network API and incremental
union are planned.
external_evidence:
completeness:
level: C2
name: Partial
confidence: medium
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- attach folder shards and read a union page with layered provenance
- chorus presentation of equivalent-but-divergent pages (union without erasure)
broken_expectations:
- incremental union maintenance and equivalence index not yet built
- write-through federation transports not yet built
out_of_scope_expectations:
- hosting or replacing the underlying wiki engines
reliability:
level: R1
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- early implementation; 64 tests but no production exposure
discovery:
intent: >
Let independently stored, differently implemented wikis behave as one
coherent, versionable, inspectable information space without homogenizing them.
includes:
- union resolution across shards (identity-keyed)
- chorus / designated-canonical presentation of equivalent pages
- lazy replication projection of remote content with freshness
excludes:
- implementing a backend wiki engine (see capability.wiki.engine-typed-extensions)
- silent remote mutation
assumptions:
- canonical truth lives in shards + a git coordination journal; the union is derived
use_cases:
- "shard-wiki UseCaseCatalog UC-01..UC-07, UC-26..UC-33 (information space, federation, coordination)"
availability:
current_level: A2
target_level: A5
current_artifacts:
- "shard-wiki/src/shard_wiki/union/"
- "shard-wiki/src/shard_wiki/space.py"
target_artifacts:
- orchestrator network API
consumption_modes:
- source module
relations:
depends_on:
- capability.wiki.adapter-contract
- capability.wiki.page-model
- capability.wiki.coordination-journal
supports:
- capability.wiki.federation-models
evidence:
documentation:
- "shard-wiki/spec/CoreArchitectureBlueprint.md"
- "shard-wiki/spec/FederationArchitecture.md"
tests:
- "shard-wiki/tests/test_union.py"
- "shard-wiki/tests/test_integration.py"
consumer_guidance:
recommended_for:
- composing multiple Markdown/wiki stores into one provenance-preserving view
not_recommended_for:
- replacing a single wiki engine
known_limitations:
- resolution is recompute-on-read until the incremental tier lands
---
# Wiki Shard Orchestration
shard-wiki's core capability: orchestrate wiki-shaped content across heterogeneous *shards*
as a union of pages, preserving provenance, capabilities, and history per shard. Canonical
truth stays at the edges (shards + the git coordination journal); the union is a derived,
recomputable view (orchestrator, not engine).
## Assessment notes
### Discovery
Grounded by `UseCaseCatalog.md` (84 UCs) and the hardened `CoreArchitectureBlueprint.md`.
### Availability
`InformationSpace` provides attach/resolve/read today (source module); a network API is the
target availability step.

View File

@@ -486,7 +486,7 @@ repos:
- slug: reuse-surface
path: /home/worsch/reuse-surface
status: established
capability_count: 20
capability_count: 3
seed_from_reuse_surface: true
seed_capability_ids:
- capability.registry.register

View File

@@ -1,6 +1,6 @@
# Manually maintained capability index for humans and agents.
version: 1
updated: "2026-06-15"
updated: "2026-06-16"
domain: helix_forge
capabilities:
- id: capability.activity.event-coordinate
@@ -14,83 +14,6 @@ capabilities:
tags: [activity, coordination, automation]
consumption_modes: [informational]
- id: capability.audit.event-retain
name: Audit Event Retention
summary: Collect, normalize, retain, and search audit events with integrity evidence across tenants.
vector: D4 / A2 / C2 / R1
domain: helix_forge
status: draft
owner: audit-core
path: registry/capabilities/capability.audit.event-retain.md
tags: [audit, retention, compliance]
consumption_modes: [source module]
- id: capability.authorization.policy-evaluate
name: Authorization Policy Evaluation
summary: Evaluate access decisions from policy-as-code rules for subjects, resources, and actions.
vector: D4 / A2 / C2 / R1
domain: helix_forge
status: draft
owner: flex-auth
path: registry/capabilities/capability.authorization.policy-evaluate.md
tags: [authorization, policy, flex-auth]
consumption_modes: [source module]
- id: capability.feature-control.evaluate
name: Feature Availability Evaluation
summary: Evaluate whether a feature is active, hidden, disabled, or unavailable for a subject in context.
vector: D5 / A4 / C3 / R3
domain: helix_forge
status: draft
owner: feature-control
path: registry/capabilities/capability.feature-control.evaluate.md
tags: [feature-control, evaluation, sdk]
consumption_modes: [SDK, service API]
- id: capability.feature-control.rollout
name: Feature Rollout Control
summary: Gradually expose features to subjects across tenants, domains, groups, or cohorts using rollout rules.
vector: D4 / A2 / C2 / R1
domain: helix_forge
status: draft
owner: feature-control
path: registry/capabilities/capability.feature-control.rollout.md
tags: [feature-control, rollout, planning]
consumption_modes: [source module, SDK]
- id: capability.feature-control.visibility
name: Feature Visibility Control
summary: Control whether features are visible or hidden for subjects without changing entitlement or authorization.
vector: D4 / A2 / C2 / R1
domain: helix_forge
status: draft
owner: feature-control
path: registry/capabilities/capability.feature-control.visibility.md
tags: [feature-control, visibility]
consumption_modes: [source module]
- id: capability.identity.subject-resolution
name: Identity Subject Resolution
summary: Resolve who or what is acting by mapping principals, accounts, actors, and identifiers to a stable subject model.
vector: D3 / A0 / C1 / R0
domain: helix_forge
status: draft
owner: identity-canon
path: registry/capabilities/capability.identity.subject-resolution.md
tags: [identity, subject, architecture]
consumption_modes: [informational]
- id: capability.identity.vocabulary-canonicalize
name: Identity Vocabulary Canonicalization
summary: Define an implementation-neutral vocabulary for identity-related concepts across overlapping domains.
vector: D4 / A0 / C2 / R0
domain: helix_forge
status: draft
owner: identity-canon
path: registry/capabilities/capability.identity.vocabulary-canonicalize.md
tags: [identity, terminology, research]
consumption_modes: [informational]
- id: capability.registry.register
name: Capability Registration
summary: Register a new capability so it becomes visible for planning and implementation reuse.
@@ -111,113 +34,4 @@ capabilities:
owner: reuse-surface
path: registry/capabilities/capability.registry.validate.md
tags: [registry, validation, cli]
consumption_modes: [cli]
- id: capability.statehub.progress-log
name: Work Progress Logging
summary: Record progress events, decisions, and session notes against workstreams and tasks in State Hub.
vector: D4 / A4 / C3 / R3
domain: helix_forge
status: draft
owner: state-hub
path: registry/capabilities/capability.statehub.progress-log.md
tags: [state-hub, progress, coordination]
consumption_modes: [service API]
- id: capability.statehub.workstream-coordinate
name: Workstream And Task Coordination
summary: Track active workstreams, tasks, progress, and consistency across domain repositories.
vector: D4 / A4 / C3 / R2
domain: helix_forge
status: draft
owner: state-hub
path: registry/capabilities/capability.statehub.workstream-coordinate.md
tags: [state-hub, coordination, workplans]
consumption_modes: [service API, HTTP REST]
- id: capability.wiki.shard-orchestration
name: Wiki Shard Orchestration
summary: Present a union of pages across heterogeneous wiki-shaped shards while preserving each shard's provenance, capabilities, and history.
vector: D5 / A2 / C2 / R1
domain: helix_forge
status: draft
owner: shard-wiki
path: registry/capabilities/capability.wiki.shard-orchestration.md
tags: [wiki, federation, orchestration, union, shard-wiki]
consumption_modes: [source module]
- id: capability.wiki.adapter-contract
name: Capability-Aware Shard Adapter Contract
summary: A versioned backend interface where each binding declares a verified capability profile, so federation ops degrade by capability.
vector: D5 / A2 / C2 / R1
domain: helix_forge
status: draft
owner: shard-wiki
path: registry/capabilities/capability.wiki.adapter-contract.md
tags: [wiki, adapter, capability, contract, conformance, shard-wiki]
consumption_modes: [source module]
- id: capability.wiki.page-model
name: Backend-Neutral Wiki Page Model
summary: A Markdown-first but stretchable page model with stable identity separate from placement and layered provenance.
vector: D5 / A2 / C2 / R1
domain: helix_forge
status: draft
owner: shard-wiki
path: registry/capabilities/capability.wiki.page-model.md
tags: [wiki, page-model, identity, provenance, markdown, shard-wiki]
consumption_modes: [source module]
- id: capability.wiki.coordination-journal
name: Event-Sourced Coordination Journal
summary: An append-only, totally-ordered-per-space decision log whose current state is a derived fold; git-addressable history.
vector: D5 / A2 / C2 / R1
domain: helix_forge
status: draft
owner: shard-wiki
path: registry/capabilities/capability.wiki.coordination-journal.md
tags: [wiki, event-sourcing, coordination, git, journal, shard-wiki]
consumption_modes: [source module]
- id: capability.wiki.overlay
name: Overlay-Before-Mutation Write Path
summary: Non-destructive edits (draft -> patch -> apply-under-drift) that let read-only or limited backends be edited safely without silent remote mutation.
vector: D5 / A2 / C2 / R1
domain: helix_forge
status: draft
owner: shard-wiki
path: registry/capabilities/capability.wiki.overlay.md
tags: [wiki, overlay, patch, write-path, conflict, shard-wiki]
consumption_modes: [source module]
- id: capability.wiki.federation-models
name: Selectable Federation-Model Taxonomy
summary: Federation as a plural, composable coordination axis (fork+journal, VCS-replication, query-join, feed, activity-streams, engine-mirror) selected per space.
vector: D4 / A0 / C1 / R0
domain: helix_forge
status: draft
owner: shard-wiki
path: registry/capabilities/capability.wiki.federation-models.md
tags: [wiki, federation, taxonomy, composable, shard-wiki]
consumption_modes: [informational]
- id: capability.wiki.engine-typed-extensions
name: Wiki Engine with Typed Extensions
summary: A small-core wiki engine realizing a typed-extension framework that addresses all wiki use cases and lets each shard activate only the features it needs.
vector: D3 / A0 / C0 / R0
domain: helix_forge
status: draft
owner: shard-wiki
path: registry/capabilities/capability.wiki.engine-typed-extensions.md
tags: [wiki, engine, typed-extensions, feature-activation, shard-wiki]
consumption_modes: [informational]
- id: capability.wiki.derived-views
name: Wiki Derived Views
summary: Recomputable views over a wiki union — BackLinks, RecentChanges, AllPages, SiteMap, and (delegate-or-derive) Search — carrying provenance.
vector: D3 / A0 / C0 / R0
domain: helix_forge
status: draft
owner: shard-wiki
path: registry/capabilities/capability.wiki.derived-views.md
tags: [wiki, derived-views, backlinks, recentchanges, search, shard-wiki]
consumption_modes: [informational]
consumption_modes: [cli]

View File

@@ -22,8 +22,12 @@ from reuse_surface.hub_sync import (
from reuse_surface.overlaps import find_overlaps
from reuse_surface.reports import (
cohort_filters_from_args,
collect_gap_report,
default_roster_path,
format_cohort_json,
format_cohort_markdown,
format_gap_json,
format_gap_markdown,
select_cohort,
)
from reuse_surface.establish import (
@@ -520,6 +524,19 @@ def cmd_report_cohorts(args: argparse.Namespace) -> int:
return 0
def cmd_report_gaps(args: argparse.Namespace) -> int:
roster_path = Path(args.roster).resolve() if args.roster else default_roster_path()
if not roster_path.exists():
print(f"error: roster not found: {roster_path}", file=sys.stderr)
return 1
report = collect_gap_report(roster_path)
if args.format == "json":
print(format_gap_json(report))
else:
print(format_gap_markdown(report), end="")
return 0
def cmd_export(args: argparse.Namespace) -> int:
index = load_index()
bundle: dict[str, Any] = {
@@ -724,6 +741,21 @@ def main(argv: list[str] | None = None) -> int:
)
cohorts.set_defaults(func=cmd_report_cohorts)
gaps = report_sub.add_parser(
"gaps",
help="roster publish blockers, empty scaffolds, and dedup stubs",
)
gaps.add_argument(
"--roster",
help="workstation roster YAML (default: registry/federation/local-repo-roster.yaml)",
)
gaps.add_argument(
"--format",
choices=["markdown", "json"],
default="markdown",
)
gaps.set_defaults(func=cmd_report_gaps)
stats = subparsers.add_parser("stats", help="registry maturity and federation stats")
stats.add_argument("--path", help="repo root (default: cwd)")
stats.add_argument(

View File

@@ -1,9 +1,12 @@
from __future__ import annotations
import json
from pathlib import Path
from typing import Any
from reuse_surface.registry import level_at_least, load_index, parse_vector
import yaml
from reuse_surface.registry import ROOT, level_at_least, load_index, parse_vector
def _availability_at_most(current: str, maximum: str) -> bool:
@@ -84,4 +87,125 @@ def format_cohort_json(matches: list[dict[str, Any]], filters: dict[str, str | N
"filters": {key: value for key, value in filters.items() if value},
"capabilities": matches,
}
return json.dumps(payload, indent=2, sort_keys=True)
return json.dumps(payload, indent=2, sort_keys=True)
def collect_gap_report(
roster_path: Path,
*,
index: dict[str, Any] | None = None,
) -> dict[str, Any]:
roster = yaml.safe_load(roster_path.read_text(encoding="utf-8"))
repos = roster.get("repos", [])
summary = roster.get("summary", {})
local_index = index or load_index()
local_by_owner: dict[str, list[str]] = {}
for row in local_index.get("capabilities", []):
owner = row.get("owner") or "unknown"
local_by_owner.setdefault(owner, []).append(row["id"])
publish_fail = [r for r in repos if r.get("publish_check") == "fail"]
empty_scaffolds = [
r for r in repos
if r.get("status") == "established" and r.get("capability_count", 0) == 0
]
seeded = [r for r in repos if r.get("seed_from_reuse_surface")]
dedup_pending = [
{
"slug": owner,
"local_ids": ids,
}
for owner, ids in sorted(local_by_owner.items())
if owner not in {"reuse-surface", "unknown"}
]
return {
"roster_path": str(roster_path),
"summary": summary,
"publish_fail": [
{
"slug": r["slug"],
"hub_registered": r.get("hub_registered"),
"publish_note": r.get("publish_note"),
}
for r in publish_fail
],
"empty_scaffold_count": len(empty_scaffolds),
"empty_scaffolds": [r["slug"] for r in empty_scaffolds],
"seeded_repos": [
{
"slug": r["slug"],
"seed_capability_ids": r.get("seed_capability_ids", []),
"publish_check": r.get("publish_check"),
}
for r in seeded
],
"dedup_pending_local_owners": dedup_pending,
"local_capability_count": len(local_index.get("capabilities", [])),
}
def format_gap_markdown(report: dict[str, Any]) -> str:
lines = ["# Registry gap report", ""]
lines.append(f"**Roster:** `{report['roster_path']}`")
summary = report.get("summary", {})
if summary:
lines.append(
f"**Workstation:** {summary.get('established', '?')}/"
f"{summary.get('total', '?')} established; "
f"publish pass {summary.get('publish_pass', '?')}/"
f"{summary.get('total', '?')}"
)
lines.append("")
fails = report.get("publish_fail", [])
lines.append(f"## Publish blocked ({len(fails)})")
if fails:
for item in fails:
note = item.get("publish_note") or ""
suffix = f"{note}" if note else ""
lines.append(f"- `{item['slug']}`{suffix}")
else:
lines.append("- none")
lines.append("")
dedup = report.get("dedup_pending_local_owners", [])
lines.append(f"## Local index owner stubs ({len(dedup)})")
if dedup:
for item in dedup:
ids = ", ".join(f"`{cap_id}`" for cap_id in item["local_ids"])
lines.append(f"- **{item['slug']}:** {ids}")
else:
lines.append("- none (owner rows migrated to canonical repos)")
lines.append("")
empty_count = report.get("empty_scaffold_count", 0)
lines.append(f"## Empty scaffolds ({empty_count})")
slugs = report.get("empty_scaffolds", [])
if slugs:
for slug in slugs:
lines.append(f"- `{slug}`")
else:
lines.append("- none")
lines.append("")
seeded = report.get("seeded_repos", [])
lines.append(f"## Seed-ready repos ({len(seeded)})")
for item in seeded:
publish = item.get("publish_check", "?")
lines.append(f"- `{item['slug']}` (publish: {publish})")
lines.append("")
lines.append(
f"**Local reuse-surface capabilities:** {report.get('local_capability_count', 0)}"
)
return "\n".join(lines) + "\n"
def format_gap_json(report: dict[str, Any]) -> str:
return json.dumps(report, indent=2, sort_keys=True)
def default_roster_path() -> Path:
return ROOT / "registry/federation/local-repo-roster.yaml"

View File

@@ -3,10 +3,14 @@ from __future__ import annotations
import argparse
import json
from pathlib import Path
from reuse_surface.reports import (
cohort_filters_from_args,
collect_gap_report,
format_cohort_json,
format_cohort_markdown,
format_gap_markdown,
select_cohort,
)
@@ -88,6 +92,38 @@ def test_format_cohort_json_payload():
assert payload["filters"]["discovery_min"] == "D5"
def test_collect_gap_report_from_roster():
root = Path(__file__).resolve().parent.parent
roster = root / "registry/federation/local-repo-roster.yaml"
report = collect_gap_report(roster)
assert report["summary"]["total"] == 60
assert len(report["publish_fail"]) == 13
assert report["empty_scaffold_count"] >= 40
def test_format_gap_markdown_lists_publish_fail():
report = {
"roster_path": "/tmp/roster.yaml",
"summary": {"total": 60, "established": 60, "publish_pass": 47},
"publish_fail": [{"slug": "hub-core", "publish_note": "missing repo"}],
"empty_scaffold_count": 1,
"empty_scaffolds": ["ops-bridge"],
"seeded_repos": [],
"dedup_pending_local_owners": [],
"local_capability_count": 3,
}
text = format_gap_markdown(report)
assert "hub-core" in text
assert "ops-bridge" in text
def test_cmd_report_gaps_json(monkeypatch):
from reuse_surface.cli import main
exit_code = main(["report", "gaps", "--format", "json"])
assert exit_code == 0
def test_cmd_report_cohorts_markdown(monkeypatch):
from reuse_surface.cli import main

View File

@@ -13,7 +13,7 @@ from reuse_surface.stats import (
def test_collect_stats_on_repo_root():
root = Path(__file__).resolve().parent.parent
stats = collect_stats(root)
assert stats["capability_count"] == 20
assert stats["capability_count"] == 3
assert stats["index_present"] is True
assert "discovery" in stats["histograms"]
@@ -22,7 +22,7 @@ def test_format_stats_markdown_contains_count():
root = Path(__file__).resolve().parent.parent
text = format_stats_markdown(collect_stats(root))
assert "Capabilities:" in text
assert "20" in text
assert "3" in text
def test_collect_roster_stats_federation_ready():

View File

@@ -104,6 +104,17 @@ reuse-surface hub sync --dry-run
Run the service locally: `REUSE_SURFACE_TOKEN=dev-token reuse-surface serve`
### report gaps
```bash
reuse-surface report gaps
reuse-surface report gaps --format json
reuse-surface report gaps --roster registry/federation/local-repo-roster.yaml
```
Workstation roster report: publish blockers, empty scaffolds, seed-ready repos,
and local index owner stubs pending dedup.
### stats
Registry maturity aggregates and federation readiness.

View File

@@ -4,7 +4,7 @@ type: workplan
title: "Federation polish and planning analytics"
domain: helix_forge
repo: reuse-surface
status: ready
status: active
owner: codex
topic_slug: helix-forge
created: "2026-06-16"
@@ -64,12 +64,17 @@ T01 (Gitea publish — operator; unblocks fetch)
```task
id: REUSE-WP-0015-T01
status: todo
status: progress
priority: high
state_hub_task_id: "7024ca46-cabd-44a8-8baf-cbc83d99c1fe"
needs_human: true
intervention_note: "13 repos Gitea raw HTTP 404 — operator must fix visibility or create hub-core repo"
```
Close gap priority **25**. Bring all roster rows to `publish_check: pass`.
Close gap priority **25**.
**2026-06-16:** Sweep re-run — all 13 still HTTP 404. No agent-side remediation
possible without Gitea operator action. Bring all roster rows to `publish_check: pass`.
**Blocked slugs (13):** `activity-core`, `hub-core`, `ihp-railiance-probe`,
`inter-hub`, `net-kingdom`, `railiance-apps`, `railiance-cluster`,
@@ -94,12 +99,16 @@ disabled).
```task
id: REUSE-WP-0015-T02
status: todo
status: done
priority: high
state_hub_task_id: "a354ef8f-fdbb-4929-8278-8ecf4ca79553"
```
Close gap priority **26**. Remove duplicate capability rows from reuse-surface
Close gap priority **26**.
**Done 2026-06-16:** Removed 17 owner-migrated rows + markdown from reuse-surface
index (kept `activity-core` stub until T01). Local index **3** entries. Compose
duplicate warnings clear after Gitea index push (`--refresh`). Remove duplicate capability rows from reuse-surface
where owner repo index is canonical and fetchable.
**Owner batches** (separate commits per owner — see dedup plan):
@@ -130,12 +139,16 @@ reuse-surface graph --check
```task
id: REUSE-WP-0015-T03
status: todo
status: done
priority: medium
state_hub_task_id: "e135ea2e-a68f-4f72-947c-abe08a3aedef"
```
Close gap priority **27**. Extend planning support beyond `report cohorts`.
Close gap priority **27**.
**Done 2026-06-16:** `reuse-surface report gaps` — roster publish blockers,
empty scaffolds, seed-ready repos, local owner stubs. Standardization tracker
deferred (overlaps + compose warnings sufficient for now). Extend planning support beyond `report cohorts`.
Deliver one or both (minimum: **gap report**):
@@ -153,13 +166,17 @@ artifact beyond overlaps/cohorts.
```task
id: REUSE-WP-0015-T04
status: todo
status: progress
priority: high
state_hub_task_id: "aa26429d-6d42-4d84-9235-96feb61303f2"
```
Verify federation health after T01 and T02.
**2026-06-16:** Duplicate-ID warnings eliminated locally after T02; pending Gitea
push + `--refresh` for remote reuse-surface source. **13** fetch warnings remain
(blocked on T01).
```bash
reuse-surface hub sync --merge
reuse-surface federation compose
@@ -179,11 +196,14 @@ grows).
```task
id: REUSE-WP-0015-T05
status: todo
status: done
priority: low
state_hub_task_id: "88f50eb3-9fba-413f-89aa-7b159f136520"
```
**Done 2026-06-16:** CI informational steps for `stats --roster --federation-ready`
and `report gaps` in `.gitea/workflows/ci.yml`.
Informational CI step (non-blocking until T01 complete):
```bash
@@ -232,4 +252,5 @@ On workplan completion:
| Date | Event |
|---|---|
| 2026-06-16 | WP-0015 created from `history/2026-06-16-intent-scope-assessment.md` |
| 2026-06-16 | WP-0015 created from `history/2026-06-16-intent-scope-assessment.md` |
| 2026-06-16 | T02 dedup (3 local entries); T03 report gaps; T05 CI; T01 operator-blocked |