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>
Standalone-app shape, instance-per-client tenancy with consolidation-ready
data model (DR-1 C), app-local identity with bounded auth module (DR-3 A),
build/release evidence, ops-hub and fin-hub obligations, data-protection
baseline. Applies to client apps and Binky Hedgehog's own apps alike
(DR-2 B client-#1 model). Awaits canon review.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
