Neither repo keeps the shared prefix. railiance-cluster switches active and
future plans (0007 backlog, 0014 ready) to RCLUSTER-WP- preserving running
numbers; railiance-bootstrap takes RBS-WP- starting at 0010, above its
historical maximum, so its finished plans could be adopted later without
collision. Finished files keep RAIL-BS-WP- per the option 2 ruling.
RAILIANCE-WP- should be retired the same way rather than awarded to one
repo; successor prefixes still outstanding.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Verified: all five duplicated identifiers are finished, and no workplan in a
live state shares an identifier. Option 2 therefore requires no renumbering
today; historical duplicates stay, RAILIANCE-WP-0015 ambiguity included.
Separates remediation from conformance: three shared prefixes remain in use
across seven repos as single concurrently-allocated number lines. RAIL-BS-
and RAILIANCE- are still growing, so the 0015/0016 collisions will recur at
the next concurrent allocation. Prefix ownership assignment tracked as
RMGR-WP-0004-T09 under decision 1, which option 2 does not exempt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
custodian-sync@railiance.local is a hardcoded default git identity in
consistency_check.py, not proof of which machine synced. The real evidence
is the timezone split (+0000 and +0200) across sync commits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Decision 2 reframed: the defect is a database-local key stored in a shared
artifact, which also inverts ADR-001. Target is UUIDv5 derived from the
globally unique PREFIX-WP-NNNN, making writeback idempotent across any
number of hub instances. Prerequisite: decision 1 uniqueness must be
enforced first, or derivation from PRJ-WP- style collisions manufactures
duplicate UUIDs.
Interim: one writer only, the automated production instance. Rejected:
collapsing to a shared database, which kills offline capability against
STATE-WP-0068. Both land in repo-manager per 747011c6.
Migration scope: 758 workplan files carry these fields. Remediation of the
3 shared prefixes and 5 duplicated identifiers stays an open ruling.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Evidence, Evidence Source, Adjudication Outcome and the general
evidence-strength dimension get a dedicated InfoTechCanon model, imported by
itc-gov, itc-ident and commerce-canon. Three named consumers predate the
model, which is the required demand signal.
itc-gov stops owning Evidence and becomes an importer; it retains
AssuranceCase, AssuranceConclusion, Audit and the Policy-Control-Evidence
pattern expressed over imported concepts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
R1 Scope -> itc-ident (itc-access keeps narrower ResourceScope).
R2 Assurance Level -> itc-ident, distinct from governance AssuranceCase.
R3 Evidence + Evidence Source are a general pair (container vs extracted
assertion), owned together, not by commerce; itc-gov no longer owns
Evidence.
R4 Relationship Tuple -> itc-access (already modelled there).
R5 Adjudication Outcome follows R3; general, not commerce-owned.
assurance_tier splits: general strength dimension vs commerce's named
Counterparty Assurance Gradient.
R6 Community + Household extend itc-org CollectiveActor; Family rejected as
a collective actor and given its own seeded concept area.
One open question remains: the home for the evidence pair (dedicated
itc-evid model vs itc-gov incumbency). Recommendation: dedicated model.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Globally unique PREFIX-WP-NNNN; one prefix per repo; forward-only running
numbers; prefixes never derived from flavor markers. Exactly one registrar
mints hub IDs into git-tracked files. Automated normalization may not
promote proposed to active. Repo manipulation defaults to a worker agent in
that repo; prj- repos may act across their declared participants.
Fleet scan of 955 workplans found 3 shared prefixes and 5 duplicated
identifiers. Migration of existing collisions deliberately left for a
separate ruling.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Proposes three federated canons (Custodian, InfoTech, Commerce) with
declared concept ownership. Renames identity-canon to commerce-canon in
place; identity content emigrates to a new InfoTechCanon model.
Assigns all ~60 identity-canon glossary concepts to exactly one owner and
lists six unresolved collisions as open questions rather than deciding
them silently.
Status is proposed — canon changes are review-gated.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Publish project-repository-flavor_v0.1 with naming, GOAL.md (not durable
INTENT.md), authority boundary, lifecycle, residuals, and archive rules.
Close ADR-005 deferred naming and CUST-WP-0050 D1a; cross-link from the
repo classification standard.
coulomb-social is registered under domain communication / topic
coulomb-social; CSOC-WP-0001 lives in that repo. Convert the seed doc
from "no owning repo" to a historical pointer.
Maintainer decision, 2026-07-29/30: adopts TRSL V1C1 as this repo's preliminary governing license, per target-revenue's workplans/TREV-WP-0008-governance-and-pilot-rollout.md T05. Full specialist legal review is deferred until out of beta (target-revenue SCOPE.md section 1). No Phase is yet declared for this repo.
This repo previously carried a Proprietary and Confidential license, explicitly confirmed by the maintainer to be superseded here rather than kept as an exception (2026-07-30).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Canon work-record-types: residuals use intake/workplan/decision with
origin residual|handoff and origin_ref parent WP. Schema origin_ref;
agent close protocol aligned.
Checked all 7 WARDEN-WP-0012-origin findings against ops-warden's live
catalog before any hand-off. 6 were already shipped weeks before this
migration (2026-07-21) -- the source suggestions just never got closed:
- CUST-IN-0001 -> issue-core-ingestion-api-key: active since 2026-07-02
(CCR-2026-0002/RAILIANCE-WP-0009, audit-verified)
- CUST-IN-0002 -> activity-core-issue-sink: active since 2026-06-18
- CUST-IN-0003 -> openrouter-llm-connect: active since 2026-07-02
(CCR-2026-0003/RAILIANCE-WP-0010, audit-verified)
- CUST-IN-0005 -> key-cape-oidc-login: active since 2026-06-27 (used
directly this session, 2026-07-20, to fetch the forgejo-admin-api-token)
- CUST-IN-0006 -> flex-auth-policy-check: active since 2026-06-18
- CUST-IN-0007 -> railiance-infra-principals: active since 2026-06-18
All 6 closed outcome: absorbed, file + hub in sync, pointing at the
shipped catalog entry. No Forgejo issue opened for these -- the fleet
doesn't use Forgejo issue tracking as a coordination mechanism (retired
2026-07-20), and this file is exactly the sanctioned equivalent.
CUST-IN-0004 (object-storage-sts) is the one real item: routed, not
closed. Its own ops-warden playbook is explicit -- "ops-warden does not
vend object-storage credentials" / "do not ask ops-warden" -- and its
tracking workplan (WARDEN-WP-0012, finished 2026-06-27) already scoped
correctly: T04 delivered the pointer playbook only, not the vending
path. Real owners per that workplan's own table: net-kingdom
(architecture), flex-auth (policy decision), railiance-platform (OpenBao
broker), artifact-store (consumer, ARTIFACT-STORE-WP-0007). References
NK-WP-0007. Left routed with full context for one of those four repos'
owners to pick up -- not implemented here, not ops-warden's to do.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Stage 3 delivered end-to-end: intake hub entity (T01), fix-consistency
registration (T02), the promotion transition (T03, the actual point of
this workplan), generated per-repo index (T04), queue closures
retargeted to it (T05), suggestions retired with a real-data migration
(T06). All live-verified against the running API/DB, not just tests --
including catching and fixing a real bug in T03 (silent false-success
on a missing repo_id). 563 tests green throughout.
Carried forward, not blocking: full transclusion rendering (markitect,
T04 follow-on), an engagement hub entity (T02's honest deferral), the
pre-existing sync_schedules bug found 2026-07-20 (TD f29e49eb, out of
scope), and the 10 migrated intake findings needing their actual domain
owners to pick them up.
The reconciliation that started with AWQ-010 is complete.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
One-time close-out of the legacy suggestions table, per the
founder-reviewed decision to retire it (fresh intake entity, not a
rename-bridge). At retirement, 10 records were still open (stage:
suggestion, never promoted/declined) -- real signal from other domains'
agents: 7 ops-warden WARDEN-WP-0012 gated routing scenarios, 2
state-hub STATE-WP-0069/0073 items, 1 binky-control repo-classification
finding. Rather than discard the signal, migrated each into a proper
file-backed intake record (CUST-IN-0001..0010) landing in this repo --
the fleet's natural holding ground for cross-domain findings with no
specific owning repo yet, since none of these ever had a file origin
(hub-first creation is exactly the anti-pattern this whole effort
exists to close).
Each carries origin: "legacy-suggestion:<uuid>" back to the retired
record. All 10 registered live against the real hub via C-32 (state_hub_intake_id
written back). WORK-RECORDS.md regenerated to include them.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
52 workplans, 332 tasks -- the-custodian's cross-cutting work-record
index, generated by the new C-33 fix-consistency check. Verified
idempotent (second run: no C-33 fix, index already current) and
performant at this repo's scale (~1.5min full fix-consistency run,
the new scan is a small fraction of that).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Traced the origin of the-custodian issues #1-5 (opened 2026-07-08, all
reviewed and closed 2026-07-20): this ActivityDefinition's matched rule
always produces a TaskSpec (rules/actions.py::_task_spec_for_rule), and
RunActivityWorkflow unconditionally routes TaskSpecs through emit_tasks
-> the deployment-wide IssueSink (ISSUE_SINK_TYPE=rest -> issue-core ->
Forgejo). It is the fleet's only consumer of the task_template rule
action -- confirmed via grep across activity-definitions/.
Per current policy (Forgejo issue tracking is not the fleet coordination
mechanism), paused rather than left to recreate the same sidetrack daily:
enabled: false, status: paused, re-enable path documented in the file
(needs a new activity-core report-sink authoring a kind: intake work
record instead of an IssueSink task spec). Added as item 6 to
CUST-WP-0060's stage-3 successor seed, including the reminder to grep the
fleet for any other task_template consumer before stage 3 ships.
This is the ADR-001 file-level fix; the live activity-core DB row and
Temporal schedule pick it up on the next Railiance-deployed
'make sync-activity-definitions' run -- not something I have credentials
or standing to trigger directly from this session.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Root-caused the xfail left in place at end of the test-coverage review:
git history (commit e0f9330, CUST-WP-0055 T02/T06/T07, 2026-07-08) shows
the agentic-resources exclude_repo: true -> path_prefixes narrowing was
deliberate, done to bring the repo's real source under the terminology
scan while still excluding the generated session_memory/.store/ tree.
The test was never updated to match and had been silently failing since.
Replaced the stale whole-repo-exclusion assertion with one that checks
the actual current contract: session_memory/.store/ stays excluded,
README.md (and everything else) is now in scope. No xfail marker needed
-- config was correct, only the test was wrong.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Critical review of CUST-WP-0060 (T03-T06) found: shipped mechanism proven
only by manual/live-repo runs, no repeatable test suite; tests/ never
wired to CI at all (pre-existing gap, not introduced here).
- tests/test_validate_work_records.py: 30 tests against the live canon
registry/schemas — classify() incl. all grandfathered legacy id
schemes, per-kind schema gates (intake open/closed/promoted, decision
prepared/resolved, engagement prepared), multi-doc yaml handling,
malformed-yaml-only-errors-if-id-registered, main() end-to-end via
subprocess (exit codes, template placeholders, --strict escalation,
terminal-record historical grace incl. the boundary case that grace
must NOT mask real enum violations), and the jsonschema-unavailable
fallback path (the exact failure mode that broke the first Forgejo
CI run before the runner-substrate fix)
- tools/validate_work_records.py: docstring said 'authoritative detector
is fix-consistency C-25' — wrong, it landed as C-31 (C-25..C-30 were
already taken); comment now correct
- .forgejo/workflows/python-tests.yaml: wires tests/ to CI for the first
time in this repo (apt python3/pytest/jsonschema/yaml on the
node:20-bookworm substrate, same pattern as work-records.yaml)
- tests/test_scan_workstream_terminology.py: found one pre-existing,
unrelated failure while establishing the CI-representative baseline
(agentic-resources allowlist entry no longer sets exclude_repo — a
policy question, not a bug this task should resolve silently); marked
xfail(strict=True) with the finding recorded so CI has a clean signal
and a silent 'fix' doesn't go unnoticed either
Local verification with apt-sourced deps (jsonschema 4.10.3, matching the
CI runner's package source, not just pip): 34 passed, 1 known xfailed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- umbrella term 'work record'; intake kind 'intake item'
- any repo file is a work-record source; generated per-repo index
(transclusion-style, markitect scope) replaces separate authored file
- engagements are their own kind
- ordering simple (lane+priority+age); deps optional; WSJF optional,
situational overload-triage only
- issue-core repositioned as third-party tracker connector (UUID<->
external id, boundary sync), out of the internal loop
- fresh intake entity in state-hub; suggestions to read-only legacy
- budgets hybrid: repo budgets.yaml + frontmatter override + global
best-guess default; enforcement programmatic, never agentic
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
