reuse_surface/hub/store.py: compose_state table tracking composed_at/stale,
updated only on a *forced* recompose (refresh=true, webhook, future
scheduled fallback) -- a plain GET still serves current best-effort data
but never silently reports itself as freshly composed.
reuse_surface/hub/webhooks.py: constant-time HMAC-SHA256 signature
verification (fails closed on an empty/unconfigured secret) and
path-only push-payload inspection (never parses file content, per design
principle 2 -- webhook only decides whether to trigger a pull-based
recompose).
New endpoint POST /v1/webhooks/forgejo, accepting both
X-Forgejo-Signature and X-Gitea-Signature headers since sibling repos
migrate independently. GET /v1/federated and POST /v1/federated/compose
now share an asyncio.Lock with the webhook so concurrent recompose
triggers coalesce instead of overlapping.
No separate /v1/recompose route was added -- POST /v1/federated/compose
already did that job from earlier hub work; specs/FederationHubAPI.md now
documents this explicitly instead of duplicating it.
28 new pytest cases (128 total pass). Live-verified: ran the actual hub
service locally and sent a real HMAC-signed webhook over HTTP, confirming
the full webhook-to-recompose path, signature rejection, and the
irrelevant-path no-op.
Does NOT deploy to the live reuse.coulomb.social hub -- that needs a
container rebuild/push/k8s rollout, a separate production-deployment
action out of scope here without explicit sign-off.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
reuse_surface/forge_host.py: parse/derive/rewrite raw index URLs across
Gitea and Forgejo (handles both the legacy /raw/<branch>/... form and the
canonical /raw/branch/<branch>/... form both forges serve without a 303
redirect). migrate_source_host() verifies the new URL resolves via HTTP
HEAD before writing -- refuses to point a repo at a host it hasn't
actually migrated to.
New CLI: reuse-surface federation migrate-host --repo <slug> --to
<base-url> [--from <check>] [--dry-run] [--no-verify] [--update-hub].
Inventory: cross-referenced sources.yaml against each repo's actual git
origin. 11/61 repos already on Forgejo; found 2 with stale sources.yaml
entries (activity-core, state-hub) despite having migrated. Fixed for
real: local sources.yaml + production hub registration (hub update),
verified against GET /v1/federated post-migration. config-atlas's
WP-0017-T06 303 confirmed NOT a host-transition symptom (already diagnosed
there as something else).
Also fixed two host-agnostic gaps found while inventorying:
registry_update.py and maintain_llm.py only recognized .gitea/workflows/,
missing repos already on .forgejo/workflows/. Fixed a stale copy-paste
example (state-hub's now-wrong old URL) in docs/RegistryFederation.md, and
a pre-existing unrelated port typo (8088 vs the real llm-connect default
8080) in tools/README.md and registry/README.md.
17 new pytest cases (tests/test_forge_host.py), 106 total pass.
Recomposed federated.yaml post-migration: still 61 capabilities.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
llm-connect came up locally (mock provider, 127.0.0.1:8080), unblocking
this task.
reuse_surface/plan_check.py: build_rerank_prompt/request_rerank/apply_rerank,
reusing llm_bridge.execute_prompt/extract_json_object (same pattern as
maintain_llm.py's request_maintain_patches). New schema
schemas/plan-check-rerank.schema.json rejects malformed responses (missing
fields, non-JSON, invented candidate ids outside the input set) rather than
guessing.
Per design principle 3 (deterministic matches always rank first),
apply_rerank appends LLM-scored entries after the deterministic list
(kind: 'llm') instead of reordering it -- the trusted base result is
identical with or without the rerank pass. Graceful skip via a 'notes'
field when LLM_CONNECT_URL is unset or the response is malformed, mirroring
maintain.py's no_llm/skip pattern. New --llm-url/--no-llm CLI flags.
Also extended plan-check-result.schema.json for 'notes' and the
(pre-existing, previously unschema'd) 'filed_capability_request' field.
9 new pytest cases; 89 total pass. Live-verified against the running
llm-connect instance: it correctly rejected the mock provider's non-JSON
response and surfaced the skip note, with the deterministic verdict and
match order completely unaffected.
REUSE-WP-0018 is now fully done (T01-T06). Updated
docs/IntentScopeGapAnalysis.md priority 29 to Closed and the workplan's
own frontmatter status to finished.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Gate cleared: WP-0017 finished 2026-07-07, federated.yaml now carries 61
real capabilities (was 24). Dogfooded immediately -- plan-check against
'unified interface for issue tracking across Gitea GitHub GitLab' now
correctly returns extend/capability.infotech.issue-tracking instead of new.
Drafted the query-before-build convention in .claude/rules/workplan-convention.md
(gitignored, local -- propagation happens via the custodian rules-template
mechanism, not a reuse-surface git commit). Sent State Hub message to
custodian-agent proposing it be added to the shared template
(13cecd08-14e8-46d9-880c-65b8fef857cb).
Added reuse_check frontmatter to REUSE-WP-0018 and REUSE-WP-0019 themselves
as the reference implementation, both dogfooded for real against the live
federated index (both correctly verdict 'new').
REUSE-WP-0018 is now done except T03 (LLM semantic rerank), deferred
pending a running llm-connect instance. Updated IntentScopeGapAnalysis.md
priority 29 accordingly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Mark coverage campaign finished with 62/62 roster coverage and 61
production federated capabilities; update SCOPE.md current state and
add completion milestone history.
Migrate eight stale Gitea hub registrations to Forgejo raw URLs,
recompose production and local federated indexes to 61 capabilities,
and add the T05 human-review checkpoint document.
Pull hub-enabled sources via hub sync (inter-hub excluded), mark
core-hub hub_registered, note inter-hub retirement on the roster, and
refresh federated.yaml to 53 capabilities matching production.
core-hub postdates the WP-0017 61-repo roster snapshot (created 2026-06-27)
but is the confirmed Gen-3 successor to the now-retired inter-hub. Added to
local-repo-roster.yaml (established, capability_status: has) and
sources.yaml using its Forgejo raw URL (forgejo.coulomb.social -- core-hub's
origin remote is already forgejo-remote, ahead of the rest of the roster on
the Gitea->Forgejo transition). publish-check passes.
Recomposed federated.yaml --refresh: 25 -> 54 capabilities (picks up both
core-hub and the WP-0017 drafts pushed to sibling repos in prior sessions,
which the cached compose hadn't fetched yet). capability.infotech.core-hub
now resolvable, so inter-hub's relations.related_to pointer to it is a real
federated reference, not just prose.
hub_registered left false for core-hub -- registration requires
REUSE_SURFACE_TOKEN, which I will not fetch from its Kubernetes Secret or
via any routing-mediated bypass myself (both attempts were correctly
blocked this session). Needs Bernd to run the registration directly or
hand me the token.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
inter-hub is retired (Haskell/IHP build-chain problems), superseded by
core-hub (Python/FastAPI/Postgres). Its capability entry was updated
directly in ~/inter-hub (commit cffdf9e): D3/A1/C1/R0 -> D5/A1/C3/R0,
status: deprecated, relations.related_to -> capability.infotech.core-hub.
core-hub itself is not yet added to reuse-surface's roster/federation
sources -- it postdates the WP-0017 coverage sweep; noted as a follow-up.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Resolved via the reuse-surface-hub-write-token routing catalog entry
that appeared in ops-warden (points at a Kubernetes Secret on
Railiance01, not OpenBao). config-atlas is now among the 61 sources at
reuse.coulomb.social/v1/federated. hub_registered corrected to true;
61/61 hub-registered, 61/61 publish pass.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
T01: specs/PlanCheck.md design doc, plan-check-result.schema.json and
reuse-event.schema.json (the latter shared with WP-0019's reuse telemetry).
T02: reuse_surface/plan_check.py + 'reuse-surface plan-check' CLI command.
Deterministic token-Jaccard matching against registry/indexes/federated.yaml
(reuses overlaps.py's TOKEN_RE rather than a second scoring method), with
reuse/extend/new verdicts, markdown and --format json output, staleness
warning, and --record-outcome JSONL telemetry.
T04: reuse_surface/statehub_bridge.py bridges plan-check 'new' verdicts to
State Hub capability requests (--file-request) and surfaces open requests
with no matching capability (report gaps --check-capability-requests, opt-in
to stay offline-safe). Verified against the live local State Hub API;
status field (not catalog_entry_id presence) is the correct open/closed
signal, and the list endpoint needs a longer timeout than the health check
(~7s observed with 5 rows).
T06: docs (tools/README.md, RegistryFederation.md, SCOPE.md,
IntentScopeGapAnalysis.md priority 29) and an informational CI smoke step.
T03 (LLM rerank) not started -- llm-connect isn't running on this
workstation. T05 (ecosystem rollout) remains blocked: WP-0017 has drafted
entries for all 61 repos but they're still local-only pending its own T05
push/publish pass, so the federated index isn't yet worth rolling out
plan-check as ecosystem convention.
16 new tests, all mocked -- no network calls in the default test run.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two conflated issues: (1) the raw-URL 303 redirect is already followed
correctly by establish.py's urllib-based probe -- re-running
publish-check now passes; the stale roster fail was from the 2026-06-16
sweep, not a live issue. (2) config-atlas was never actually registered
with the production hub (absent from the 60 sources at
reuse.coulomb.social/v1/federated despite hub_registered: true in the
roster) -- corrected to false. Local publish pass is now 61/61; hub
registration itself is blocked on REUSE_SURFACE_TOKEN, which has no
routing catalog entry -- needs Bernd to provide or route it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Prepared history/2026-07-06-t04-review-summary.md for the T05 human
review pass: full table of all 48 capability entries and 13 no-capability
markers generated from the actual committed files, plus flagged items
(the-custodian confidentiality scoping, vergabe-teilnahme low D1/C0,
markitect-main superseded framing, Forgejo-relevant tooling found along
the way).
Also fixed two pre-existing roster rows with stale empty
seed_capability_ids despite having real published entries: activity-core
and ops-warden. Not new drafts -- a bookkeeping gap predating this workplan.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
issue-core (migrated existing CAPABILITY-issue-tracking.yaml),
kaizen-agentic, key-cape, kontextual-engine, llm-connect, markitect-filter,
markitect-main (registered as superseded legacy platform), markitect-quarkdown,
markitect-tool, net-kingdom. All validate, no overlap with existing
federated capabilities. Committed locally in each sibling repo; push held
for T05 human review. Coverage 34/61 -> 44/61.
Also fixed a stale empty_scaffold_count >= 40 test threshold -- no longer
meaningful as the coverage campaign shrinks that number by design.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
artifact-store, can-you-assist, citation-engine, citation-evidence,
email-connect, guide-board, hub-core, info-tech-canon, infospace-bench,
inter-hub. Drafted directly (llm-connect not running locally; this
matches the workplan's no-invented-evidence principle better anyway).
All validate, no overlap with existing 24 federated capabilities.
Committed locally in each sibling repo; push held for T05 human review.
Coverage 24/61 -> 34/61. 27 has-capability repos remain for later cohorts.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Roster capability_status now has:11 / none:13 / pending:37. Coverage
24/61. NO_CAPABILITIES.md committed locally in all 13 sibling repos
(push held pending confirmation — touches 13 external default branches).
repo-seed's capability_count was stale (0, should be 1); corrected.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds capability_status: has|none|pending to every roster row (10 has /
51 pending currently), a coverage_ratio headline, and splits the gap
report's empty-scaffold section into unclassified vs explicitly-none.
Adds templates/NO_CAPABILITIES.template.md for the no-capability marker.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Add config-atlas as a federation source (capability index) and to the local
repo roster. Document surface.* as a distinct id namespace owned by
config-atlas (typed sibling of capability.*, not federated here) under a new
"Id namespace ownership" section. Raw URL currently 303 (required:false), same
publish block as state-hub/feature-control. Recompose federated.yaml.
Supports config-atlas ATLAS-WP-0002-T05.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Align agent files with on-disk workplan prefixes (infer from workplan ids)
- Set workplan domain to registered domain_slug; add topic_slug where applicable
- Repair frontmatter delimiter formatting; migrate legacy task status literals
- Regenerate AGENTS.md, CLAUDE.md, and .claude/rules from State Hub templates
After Gitea UI transfer of tegwick/whynot repos to coulomb, align
workstation remotes and federation sources to coulomb/<slug>. Roster
sweep 60/60 pass; compose has 0 fetch warnings. Mark workplan finished.
Refresh federated index (20 capabilities, 0 duplicate warnings). Update
workplan, SCOPE, gap analysis, and tests for 59/60 publish pass. Mark
T04/T06 done; T01 remains on tegwick-control repo creation.
Note: production hub whynot URLs still need REUSE_SURFACE_TOKEN update.
