ui rules established

.claude/rules/first-session.md

@@ -1,11 +1,11 @@
 ## First Session Protocol
 
-Triggered when `get_domain_summary("custodian")` shows **no workstreams**.
+Triggered when `get_domain_summary("infotech")` shows **no workstreams**.
 The project is registered but work has not yet been structured.
 
 **Step 1 — Read, don't write**
-- `~/the-custodian/canon/projects/custodian/project_charter_v0.1.md` — purpose, scope
+- `~/the-custodian/canon/projects/infotech/project_charter_v0.1.md` — purpose, scope
-- `~/the-custodian/canon/projects/custodian/roadmap_v0.1.md` — planned phases
+- `~/the-custodian/canon/projects/infotech/roadmap_v0.1.md` — planned phases
 - Scan repo root: README, directory structure, existing code or docs
 
 **Step 2 — Survey in-progress work**
@@ -17,7 +17,7 @@ roadmap phase. **Wait for approval before creating.**
 
 **Step 4 — Create workplan file first, then DB record (ADR-001)**
 ```
-workplans/activity-core-WP-NNNN-<slug>.md   ← write this first
+workplans/ACTIVITY-WP-NNNN-<slug>.md   ← write this first
 ```
 Then register in the hub:
 ```
@@ -28,7 +28,7 @@ create_task(workstream_id="<id>", title="...", priority="high|medium|low")
 **Step 5 — Record the setup**
 ```
 add_progress_event(
-    summary="First session: structured custodian into N workstreams, M tasks",
+    summary="First session: structured infotech into N workstreams, M tasks",
     event_type="milestone",
     topic_id="cee7bedf-2b48-46ef-8601-006474f2ad7a",
     detail={"workstreams": [...], "tasks_created": M}

.claude/rules/repo-identity.md

@@ -1,5 +1,5 @@
 **Purpose:** Durable task factory built on Temporal. Manages ActivityDefinitions, schedules recurring workflows via Temporal Schedules, routes events via NATS JetStream, and exposes a FastAPI CRUD surface for the custodian domain.
 
-**Domain:** custodian
+**Domain:** infotech
 **Repo slug:** activity-core
 **Topic ID:** cee7bedf-2b48-46ef-8601-006474f2ad7a

.claude/rules/session-protocol.md

@@ -1,6 +1,7 @@
 ## Session Protocol
 
-State Hub: http://127.0.0.1:8000
+Dev Hub (State Hub API): http://127.0.0.1:8000
+MCP server name in `~/.claude.json`: `dev-hub`
 
 **Step 1 — Orient**
 
@@ -10,7 +11,7 @@ cat .custodian-brief.md
 ```
 Then call the MCP tool for richer cross-domain context when MCP tools are exposed:
 ```
-get_domain_summary("custodian")
+get_domain_summary("infotech")
 ```
 If MCP tools are unavailable in the current agent session, use the REST API:
 ```bash
@@ -39,11 +40,11 @@ curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
 ls workplans/
 ```
 For each file with `status: ready`, `active`, or `blocked`, note pending
-`todo`/`in_progress` tasks.
+`wait`/`todo`/`progress` tasks.
 
 **Step 4 — Present brief**
 
-1. **Active workstreams** for `custodian` — title, task counts, blocking decisions
+1. **Active workstreams** for `infotech` — title, task counts, blocking decisions
 2. **Pending tasks** from `workplans/` + any `[repo:activity-core]` hub tasks
 3. **Goal guidance** — if `goal_guidance` in summary:
    - `needs_workplan`: surface as top action — *"Repo goal '{title}' has no workplan yet"*

.claude/rules/workplan-convention.md

@@ -1,7 +1,7 @@
 ## Workplan Convention (ADR-001)
 
-File location: `workplans/activity-core-WP-NNNN-<slug>.md`
+File location: `workplans/ACTIVITY-WP-NNNN-<slug>.md`
-ID prefix: `ACTIVITY-WP`
+ID prefix: `ACTIVITY-WP-`
 
 Work items originate as files in this repo **before** being registered in the hub.
 
@@ -12,7 +12,7 @@ repo state, and `finished` when implementation is complete. `stalled` and
 `needs_review` are derived health labels, not stored statuses.
 
 Closed workplans may be moved to `workplans/archived/` with a completion-date
-prefix: `YYMMDD-activity-core-WP-NNNN-<slug>.md`. The frontmatter id remains
+prefix: `YYMMDD-ACTIVITY-WP-NNNN-<slug>.md`. The frontmatter id remains
 unchanged; the prefix is only for quick visual reference.
 
 Small opportunistic tasks discovered during another session use **Ad Hoc Tasks**:
@@ -25,4 +25,16 @@ Ecosystem todos from other agents arrive as `[repo:activity-core]` hub tasks —
 visible at session start. Pick one up by creating the workplan file, then registering
 the workstream.
 
+Task blocks use this shape:
+
+```task
+id: ACTIVITY-WP-NNNN-T01
+status: wait | todo | progress | done | cancel
+priority: high | medium | low
+state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
+```
+
+Status progression is `todo` → `progress` → `done`; use `wait` for waiting or
+blocked work and `cancel` for stopped work.
+
 <!-- Ralph Loop rules and HEUREKA sequence: ~/.claude/CLAUDE.md — do not duplicate here -->

AGENTS.md

@@ -4,7 +4,7 @@
 
 **Purpose:** Durable task factory built on Temporal. Manages ActivityDefinitions, schedules recurring workflows via Temporal Schedules, routes events via NATS JetStream, and exposes a FastAPI CRUD surface for the custodian domain.
 
-**Domain:** custodian
+**Domain:** infotech
 **Repo slug:** activity-core
 **Topic ID:** `cee7bedf-2b48-46ef-8601-006474f2ad7a`
 **Workplan prefix:** `ACTIVITY-WP-`
@@ -83,7 +83,7 @@ curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
 1. `cat .custodian-brief.md` — domain goal and open workstreams (offline-safe)
 2. Check inbox: `GET /messages/?to_agent=activity-core&unread_only=true`; mark read
 3. Scan workplans: `ls workplans/` — note `status: ready`, `active`, or `blocked` files and open tasks
-4. Check blocked tasks: `GET /tasks/?needs_human=true`
+4. Check human-needed tasks: `GET /tasks/?needs_human=true`
 
 **During work:**
 - Update task statuses in workplan files as tasks progress
@@ -151,27 +151,10 @@ every repo's agent instructions because it is high-frequency, high-risk, and eas
 get wrong.
 
 **Canon:** `~/ops-warden/wiki/CredentialRouting.md` · catalog `~/ops-warden/registry/routing/catalog.yaml`
----
 
-## Issue-core emission (`ISSUE_SINK_TYPE=rest`)
+<!-- REPO-AGENTS-EXTENSIONS -->
-
+<!-- Append repo-specific agent instructions below this marker.
-activity-core emits tasks to issue-core via `IssueCoreRestSink` (`src/activity_core/issue_sink.py`).
+     The state-hub template sync preserves content after this line. -->
-
-**Do not request `ISSUE_CORE_API_KEY` from ops-warden** — ops-warden issues SSH
-certs only. For routing: `warden route show activity-core-issue-sink --json`.
-
-| Env var | Purpose |
-| --- | --- |
-| `ISSUE_CORE_URL` | issue-core base URL (default `http://127.0.0.1:8765`) |
-| `ISSUE_CORE_API_KEY` | Shared ingestion key — sent as `Authorization: Bearer` |
-| `ISSUE_SINK_TYPE` | `rest` (live POST) or `null` (dry-run; Railiance default) |
-
-**Local dev:** generate one key, export on both activity-core and issue-core
-processes. See `docs/issue-core-emission-boundary.md` and issue-core `README.md`.
-Use `default: local` in issue-core `backends.json` for local smoke.
-
-**Production:** inject the same key on both sides via OpenBao/K8s (coordinate
-`railiance-platform` when the canonical path ships).
 
 ---
 
@@ -198,7 +181,7 @@ anything needing analysis, design, approval, dependencies, or multiple phases.
 id: ACTIVITY-WP-NNNN
 type: workplan
 title: "..."
-domain: custodian
+domain: infotech
 repo: activity-core
 status: proposed | ready | active | blocked | backlog | finished | archived
 owner: codex
@@ -228,10 +211,7 @@ state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
 Task description text.
 ```
 
-Status progression: `todo` → `progress` → `done`; use `wait` for a task
+Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blocked work and `cancel` for stopped work.
-blocked on external input and `cancel` for intentionally abandoned work.
-Workstream/workplan lifecycle status is separate; frontmatter `blocked` remains
-valid there.
 
 To create a new workplan:
 1. Write the file following the format above