@chanlerdev/scorel 0.0.1

package/docs/spec/ship/S0052-follow-up-queue-and-dual-loop.md

@@ -0,0 +1,195 @@
+# S0052 — Follow-Up Queue And Dual Loop Runtime
+
+## Goal
+
+实现 Scorel 的双 loop runtime 调度模型：
+
+- outer loop 消费 follow-up queue，把排队输入变成下一条真实 `user_message`
+- inner loop 执行当前 user turn，并消费 steer guidance
+- 用 JSONL control events 持久化 queue state，避免 daemon 崩溃或 reconnect 后丢失 follow-up
+- 保证 follow-up 消费时的 `parentId` 指向当前 final leaf，而不是排队时的中间 leaf
+
+本 spec 建立 queue control event 和双 loop，不实现 Skill index。
+
+## Why Now
+
+运行中的用户输入有两种不同语义：
+
+- `steer`：引导当前 turn，属于 inner loop guidance。
+- `follow_up`：排队等待当前 turn 结束后执行，属于 outer loop input queue。
+
+如果 follow-up 在收到时直接写成 `user_message`，它的 parent 会挂到当前中间 leaf，破坏 conversation graph。正确做法是先持久化 queue state，等当前 turn 结束后再消费成真正的 user message。
+
+## Scope
+
+### 1. Control Event
+
+新增 queue control event：
+
+```typescript
+type QueueName = "follow_up" | "steer";
+
+interface QueueItem {
+  id: string;
+  content: ScorelMessage["content"];
+  createdAt: number;
+  updatedAt: number;
+  clientId: ClientId;
+  data?: Record<string, unknown>;
+}
+
+interface QueueUpdateEvent extends PersistentEventBase {
+  type: "queue_update";
+  queue: QueueName;
+  operation: "rewrite";
+  items: QueueItem[];
+  anchorEventId: EventId | null;
+}
+```
+
+V1 只支持 full rewrite。Add、edit、delete 都通过写入完整 queue snapshot 表达。
+
+理由：
+
+- queue 很小，重复写完整状态成本低。
+- replay 简单，最后一条 rewrite 就是当前 queue。
+- UI 同步更直接。
+
+### 2. Control Events Do Not Enter Conversation Tree
+
+`queue_update` 是 control event：
+
+- 写入 JSONL
+- replay 时更新 queue state
+- 不参与 `SessionTree.getPath()`
+- 不进入 `buildContext()` message list
+
+`parentId` 对 control event 不表达 conversation parent。V1 可以保留 `parentId: null` 或迁移为 control-only base，但 public 语义必须明确：conversation order 由 thread parent 表达，control state 由 JSONL seq replay 表达。
+
+### 3. Outer Loop
+
+daemon turn loop 必须变成：
+
+```text
+while true:
+  if followUpQueue has item:
+    consume first item
+    append user_message(parent = current final leaf, meta.source = "follow_up")
+    run inner loop
+    continue
+
+  wait for normal user send_message
+  append user_message(parent = requested parent or active leaf)
+  run inner loop
+```
+
+消费 follow-up 时：
+
+- append `user_message`
+- `message.meta.source = "follow_up"`
+- `message.meta.queueItemId = queueItem.id`
+- append `queue_update` rewrite，移除已消费 item
+
+### 4. Inner Loop
+
+inner loop 执行当前 user turn：
+
+```text
+while runtime needs continuation:
+  build context
+  execute model/tool step
+  persist assistant/tool_result
+  check steer queue
+  if steer exists:
+    consume steer
+    append harness_item kind=steer origin=user
+    continue
+```
+
+`steer` 可以也用 `queue_update` 管理，但消费后必须变成 `harness_item`，而不是 `user_message`。
+
+### 5. IDs And Ordering
+
+示例：
+
+```text
+e1 user_message parent=null
+e2 assistant_message parent=e1
+e3 tool_result parent=e2
+q1 queue_update queue=follow_up items=[fu1] anchorEventId=e3
+e4 assistant_message parent=e3
+q2 queue_update queue=follow_up items=[] anchorEventId=e4
+e5 user_message parent=e4 meta.source=follow_up meta.queueItemId=fu1
+```
+
+关键规则：
+
+- JSONL `seq` 是物理 replay 顺序。
+- `parentId` 是 conversation graph。
+- follow-up 排队时的 `anchorEventId` 只用于审计/UI，不决定后续 user message parent。
+- follow-up 消费后的 user message parent 必须是当前 final leaf。
+
+## Explicitly Not In Scope
+
+- 多优先级 queue。
+- background task scheduler。
+- WebUI 完整 queue 编辑 UI。
+- branch/rewind 的完整 queue conflict UI。
+- Skill discovery / Skill tool。
+
+## Required Tests
+
+### Protocol / Session
+
+- `queue_update` round-trip 通过。
+- replay queue rewrite 能恢复当前 queue state。
+- `queue_update` 不进入 `buildContext()`。
+- `queue_update` 不成为 conversation leaf。
+
+### Follow-Up
+
+- 当前 turn 中收到 follow-up 后，JSONL 写入 queue state，但不立即产生 user message。
+- 当前 turn 结束后，follow-up 被消费成新的 `user_message`。
+- 消费后的 `user_message.parentId` 指向当前 final leaf。
+- edit/delete 通过 rewrite 生效。
+
+### Steer
+
+- steer queue item 在 inner loop 消费成 `harness_item kind=steer`。
+- steer 不变成 follow-up user message。
+
+### Runtime
+
+- follow-up queue 连续多条时，outer loop 逐条消费。
+- daemon restart 后可以从 JSONL 恢复未消费 follow-up queue。
+
+## Likely Files
+
+```text
+packages/protocol/src/events.ts
+packages/core/src/session/index.ts
+packages/core/src/session/session.test.ts
+packages/daemon/src/index.ts
+packages/daemon/src/index.test.ts
+packages/client/src/*
+apps/webui/*
+docs/spec/events.md
+docs/spec/runtime.md
+docs/spec/session.md
+```
+
+## Risks And Boundaries
+
+- 不要把 follow-up 存成普通 user message 再等待消费；那会污染 parent graph。
+- 不要把 queue state 放进 daemon-only memory；必须能从 JSONL replay。
+- 不要用 JSONL 行顺序替代 conversation parent。
+- 如果当前 session branch/leaf 切换，follow-up 消费必须以消费时 active leaf 为 parent。
+
+## Done When
+
+- follow-up add/edit/delete/rewrite 都以 `queue_update` control event 持久化。
+- daemon outer loop 会在当前 turn 完成后消费 follow-up。
+- steer 和 follow-up 分别走 inner guidance 与 outer queued input。
+- `buildContext()` 不包含 queue control events。
+- 自动测试与 typecheck 通过。
+- 完成后 commit：`S0052: feat: add follow-up queue dual loop`

package/docs/spec/ship/S0053-skill-index-and-skill-tool.md

@@ -0,0 +1,252 @@
+# S0053 — Skill Index And Skill Tool
+
+## Goal
+
+按 Agent Skills 目录规范为 Scorel 增加 Skill baseline：
+
+- 扫描 `~/.scorel/skills` 和 project `.scorel/skills`
+- 建立 session-scoped Skill index，作为 Skill tool 的路由表
+- 用 JSONL control events 持久化 skill index snapshot/delta
+- 通过 `harness_item` 注入 skill listing / skill delta
+- 暴露 `Skill(name)` 工具，按 index 加载完整 `SKILL.md`
+
+本 spec 不做 Skill discovery ranking、不做 embedding/LLM 搜索、不做 marketplace。
+
+## Why Now
+
+S0051/S0052 建立了 harness item 与 queue control event。Skill 需要同样的原则：
+
+- natural-language listing 只是给模型看的提醒，不是事实来源
+- 工具调用必须查结构化 routing table
+- session resume 后必须从 JSONL 恢复当时的 skill index
+
+否则 `Skill("name")` 会依赖磁盘即时状态和 prompt 文本，无法审计和恢复。
+
+## Scope
+
+### 1. Directory Layout
+
+V1 支持：
+
+```text
+~/.scorel/skills/<skill-name>/SKILL.md
+<project-scope>/.scorel/skills/<skill-name>/SKILL.md
+```
+
+Project-scope discovery：
+
+- 从 session `cwd` 往上查找 `.scorel/skills`
+- 如果在 Git repository 内，在最近 Git root 停止
+- 如果不在 Git repository 内，在 home 前停止
+- `~/.scorel/skills` 作为 user global 独立加载
+
+V1 只支持目录格式，不支持单个 `.md` 文件作为 skill。
+
+### 2. Name And Routing
+
+调用名以目录名为准：
+
+```text
+~/.scorel/skills/commit/SKILL.md -> Skill("commit")
+```
+
+frontmatter `name` 只作为 display name，不改变 tool routing key。
+
+理由：
+
+- Skill tool 调用必须有稳定、可预测的 key。
+- 不规范 skill 不能通过正文或 display name 改变路由。
+- listing/reminder 给模型看的 name 必须是可调用 name。
+
+### 3. Skill Index
+
+```typescript
+interface SkillIndexEntry {
+  name: string;
+  path: string;
+  scope: "user" | "project";
+  description: string;
+  displayName?: string;
+  mtimeMs: number;
+  size: number;
+  contentHash: string;
+  priority: number;
+  shadowed?: boolean;
+  diagnostics?: string[];
+}
+
+interface SkillIndexSnapshotEvent extends PersistentEventBase {
+  type: "skill_index_snapshot";
+  anchorEventId: EventId | null;
+  entries: SkillIndexEntry[];
+}
+
+interface SkillIndexDeltaEvent extends PersistentEventBase {
+  type: "skill_index_delta";
+  anchorEventId: EventId | null;
+  added: SkillIndexEntry[];
+  changed: SkillIndexEntry[];
+  removed: { name: string; previousPath: string }[];
+}
+```
+
+Replay：
+
+```text
+skill_index_snapshot -> state.skillIndex = entries by name
+skill_index_delta    -> patch state.skillIndex
+```
+
+The session state map is the source of truth for `Skill(name)`.
+
+### 4. Scan And Diff
+
+Before each real user message:
+
+1. stat known skill paths and candidate skill directories
+2. only read/parse changed files
+3. build current index
+4. compare with replayed session index
+5. append `skill_index_snapshot` if no index exists
+6. append `skill_index_delta` if added/changed/removed exists
+7. append corresponding `harness_item` listing/delta for the model
+
+No diff means no event.
+
+### 5. Listing And Delta Injection
+
+Initial listing:
+
+```text
+The following skills are available for use with the Skill tool:
+
+- commit: Create a concise semantic commit...
+- verify: Run the project's verification flow...
+```
+
+Delta:
+
+```text
+Skill updates detected:
+
+Added:
+- deploy: ...
+
+Changed:
+- verify: ...
+
+Removed:
+- old-skill
+```
+
+Both use `harness_item` and `<system-reminder>` conversion from S0051.
+
+### 6. Skill Tool
+
+Expose a builtin tool:
+
+```typescript
+Skill({ name: string, args?: string })
+```
+
+Execution:
+
+- lookup `state.skillIndex[name]`
+- if missing, return structured error listing known names
+- read `entry.path`
+- return the full `SKILL.md` content as a tool result or harness item payload for the next LM step
+- record invoked skill metadata for display/diagnostics
+
+V1 does not execute arbitrary scripts from skill directories. It only loads instructions and allows the model to inspect referenced files through normal tools.
+
+### 7. Conflict Rules
+
+Priority:
+
+1. nearest project `.scorel/skills`
+2. higher project `.scorel/skills`
+3. user `~/.scorel/skills`
+
+Same `name`:
+
+- highest priority wins
+- losing entries are shadowed
+- diagnostics records shadowed paths
+- listing only includes winning entries
+
+Invalid skill:
+
+- missing `SKILL.md`: ignored
+- missing description: derive from frontmatter or first paragraph
+- still no description: do not list; keep diagnostics
+- unreadable file: do not list; keep diagnostics
+
+## Explicitly Not In Scope
+
+- Automatic skill search/ranking.
+- Embedding search or small-model skill search.
+- Plugin/marketplace skills.
+- MCP skills.
+- Running skill scripts automatically.
+- User-facing `/skills` management UI.
+- Conditional `paths` activation beyond parsing and preserving metadata.
+
+## Required Tests
+
+### Discovery
+
+- user skills are loaded from `~/.scorel/skills`.
+- project skills are loaded from cwd upward to Git root or home boundary.
+- directory name is the tool routing key.
+- frontmatter display name does not change routing key.
+- same-name project skill shadows user skill.
+
+### Index Events
+
+- first scan writes `skill_index_snapshot`.
+- added/changed/removed skill writes `skill_index_delta`.
+- replay from JSONL reconstructs skill index.
+- no diff writes no event.
+
+### Harness Injection
+
+- initial snapshot emits `harness_item kind=skill_listing`.
+- delta emits `harness_item kind=skill_delta`.
+- listing/delta do not become routing source; state.skillIndex remains source of truth.
+
+### Skill Tool
+
+- `Skill("name")` loads content from indexed path.
+- missing skill returns structured error.
+- changed skill content is loaded after delta replay updates index.
+
+## Likely Files
+
+```text
+packages/protocol/src/events.ts
+packages/core/src/session/index.ts
+packages/core/src/session/session.test.ts
+packages/core/src/tools/*
+packages/daemon/src/index.ts
+packages/daemon/src/index.test.ts
+packages/daemon/src/skills/*
+docs/spec/events.md
+docs/spec/runtime.md
+docs/spec/extensions.md
+```
+
+## Risks And Boundaries
+
+- Do not parse harness reminder text to rebuild skill state.
+- Do not trust frontmatter `name` as routing key.
+- Do not rescan full file contents every turn when stat/hash can avoid it.
+- Do not make Skill discovery ranking part of V1; available listing plus explicit Skill tool is enough.
+
+## Done When
+
+- Scorel maintains a session-scoped skill index from JSONL snapshot/delta events.
+- Skill listing/delta are injected through harness items.
+- `Skill(name)` routes through the index and loads `SKILL.md`.
+- Resume reconstructs the same skill index before tool invocation.
+- Automatic tests and typecheck pass.
+- 完成后 commit：`S0053: feat: add skill index and skill tool`

package/docs/spec/ship/S0054-webui-running-message-behavior.md

@@ -0,0 +1,72 @@
+# S0054: WebUI Running Message Behavior
+
+## Goal
+
+Make WebUI message sending match Codex-style running behavior:
+
+- idle sends clear once the daemon's persistent event stream confirms the user message, not when the assistant finishes
+- while a run is active, the composer remains editable
+- running sends can either queue a follow-up or steer the active run
+- users can choose the default running behavior in Settings
+- `Command+Enter` sends with the default behavior, while `Command+Shift+Enter` sends the opposite behavior
+
+## Scope
+
+- Extend the protocol `send_message` options with explicit running behavior: `follow_up` or `steer`.
+- Preserve existing CLI/client request semantics: `send_message` responses remain completion/queue responses, not accepted acknowledgements.
+- Let WebUI clear the composer from the canonical persistent event stream instead of a second request-level accepted acknowledgement.
+- Add WebUI settings storage for default running behavior.
+- Update the session composer so Enter inserts a newline, `Command+Enter` sends, and `Command+Shift+Enter` sends the opposite running behavior.
+- Show both send and cancel controls while a run is active.
+
+## Non-Goals
+
+- Full queue editing UI.
+- Deleting queued follow-ups.
+- Rich steer/follow-up transcript controls beyond existing event rendering.
+- Changing CLI input behavior.
+
+## Contract
+
+`send_message` defaults remain compatible:
+
+- idle requests resolve after the user turn completes
+- no `runningBehavior` option while a run is active means `follow_up`
+
+WebUI submits:
+
+```ts
+options: {
+  runningBehavior: "follow_up" | "steer"
+}
+```
+
+WebUI treats daemon acceptance as confirmed when it observes the matching persistent event:
+
+- idle: the daemon has appended and broadcast the source `user_message`
+- running + follow-up: the daemon has appended the `queue_update` for `follow_up`
+- running + steer: the daemon has appended the `queue_update` for `steer`
+
+`send_message` responses resolve when:
+
+- idle: the user turn finishes
+- running + follow-up: the queued follow-up is consumed and finishes
+- running + steer: the steer queue item is accepted and queued; it does not create a user turn
+
+## Acceptance Criteria
+
+- WebUI composer clears and becomes editable after the matching persistent `user_message` or `queue_update`, before assistant completion.
+- While `inFlight`, users can type another message.
+- While `inFlight`, normal send uses the configured default behavior.
+- While `inFlight`, `Command+Shift+Enter` sends the opposite behavior.
+- Settings exposes a persistent default running behavior selector.
+- Follow-up sends append `queue_update(queue="follow_up")`.
+- Steer sends append `queue_update(queue="steer")` and is later consumed into a `harness_item kind="steer"`.
+- `pnpm typecheck` and `pnpm test` pass.
+
+## Test Requirements
+
+- Protocol round-trip covers the new send options and response shapes.
+- Daemon tests cover durable persistent acceptance for idle sends, follow-up queue, and steer queue.
+- WebUI composer tests cover editable in-flight input, `Command+Enter`, `Command+Shift+Enter`, send+cancel controls, and early clear.
+- Settings store tests cover default behavior persistence.

package/docs/spec/ship/S0055-webui-composer-acceptance-and-queue-strip.md

@@ -0,0 +1,68 @@
+# S0055: WebUI Composer Acceptance And Queue Strip
+
+## Goal
+
+Tighten the S0054 running composer behavior so the UI matches the actual daemon event model:
+
+- focused composer controls must not show the heavy global black outline shown in browser screenshots
+- send acceptance remains based on persistent events, but missing live events must recover through resync instead of hanging
+- running follow-up / steer queue items are visible above the input as a small actionable stack
+- project picking uses one shared Codex-like menu from both title and toolbar triggers, with a bounded scroll window and an add-project action
+
+## Scope
+
+- Override the global focus-visible outline inside the composer pill and keep the pill's own subtle border as the focus affordance.
+- Track `queue_update` events in the WebUI projector state.
+- Render queued `follow_up` / `steer` items above the textarea inside the composer, with the next item closest to the input.
+- Let visible queue rows switch between follow-up / steer, return to the input for editing, or be deleted via persistent queue rewrite.
+- Keep the project picker menu compact, scrollable, and wired to the existing Add Project dialog.
+- If a `send_message` request completes but the matching persistent event was not observed live, trigger `resync_events` from the current anchors and resolve from the recovered persistent event.
+- If send fails before acceptance, restore the input and surface `send_failed` / `disconnected` as today.
+
+## Non-Goals
+
+- Reordering queued items.
+- Rich queue history in the transcript.
+- New daemon protocol messages for queue display.
+- Treating heartbeat as send acceptance. Heartbeat only proves the socket is alive; persistent event or resync proves durable session state.
+
+## Contract
+
+For WebUI send acceptance:
+
+1. live matching persistent `user_message` / `queue_update` resolves the send immediately;
+2. request failure rejects the send;
+3. request completion without live acceptance triggers `resync_events`;
+4. resync still missing the matching persistent event rejects as `send_failed`.
+
+For queue display:
+
+- `queue_update(queue="follow_up")` replaces the displayed follow-up stack.
+- `queue_update(queue="steer")` replaces the displayed steer stack.
+- Display order is stack-like: the oldest/next item is rendered closest to the textarea.
+- Queue rows expose controls to convert follow-up/steer, edit back into the composer input, and delete the row.
+- Convert/edit/delete are persisted by a daemon `rewrite_queue` request that appends a full `queue_update(operation="rewrite")`, matching S0052.
+
+For project picking:
+
+- The title and toolbar project pickers are two triggers for the same menu component.
+- The menu has a bounded, scrollable project list and does not render native `select` controls.
+- The menu exposes an Add Project action that opens the existing shell Add Project dialog.
+
+## Acceptance Criteria
+
+- The composer textarea does not draw the heavy black focus outline.
+- Follow-up and steer queue items render above the textarea while a run is active.
+- Follow-up and steer queue rows expose convert, edit, and delete controls.
+- The project picker menu is compact, scrollable, shared by both triggers, and can open Add Project.
+- A send whose matching persistent event arrives through resync resolves successfully.
+- A send whose request completes but resync cannot find the matching persistent event fails instead of hanging.
+
+## Test Requirements
+
+- Composer tests cover no global outline class, queue strip rendering, and queue row actions.
+- Empty composer and sidebar tests cover shared project picker menu scroll bounds and Add Project wiring.
+- Protocol/client/daemon tests cover `rewrite_queue` appending persistent `queue_update` rewrites.
+- Projector tests cover `queue_update` projection and replacement.
+- Session controller tests cover request-complete resync recovery and missing-event failure.
+- `pnpm typecheck` and `pnpm test` pass.

package/docs/spec/ship/S0056-relay-and-hosted-webui-contract.md

@@ -0,0 +1,106 @@
+# S0056: Relay And Hosted WebUI Contract
+
+## Goal
+
+Lock the next product-stage contract for Relay + hosted WebUI before implementation:
+
+- Relay is an authenticated proxy and authorization registry, not a hosted daemon.
+- Hosted WebUI can connect to user Devices through Relay without requiring public daemon exposure.
+- Device -> Project -> Session remains the product hierarchy.
+- Existing daemon wire payloads stay Host-owned; Relay only adds routing and authorization around the transport.
+
+## Scope
+
+- Add `docs/spec/relay.md` as the abstract Relay contract.
+- Add ADR-007 to lock Relay proxy, `deviceId -> clientId` binding, and no new JSONL actor field.
+- Update architecture docs to show Relay as a transport/control-plane extension.
+- Update client spec to include `RelayTransport` and multi-connector Device semantics.
+- Document the implementation directory boundary: `apps/relay` for the deployable service, shared types in `packages/protocol`, `RelayTransport` in `packages/client`, Host outbound adapter in `packages/daemon`.
+- Update roadmap so Relay + Hosted WebUI becomes the next M stage and GUI/SSH/HTTP move after it.
+- Create the first M8 implementation specs: S0057 through S0060.
+
+## Non-Goals
+
+- Implement Relay service code.
+- Implement `RelayTransport`.
+- Implement `scorel pair`.
+- Implement hosted WebUI pairing UI.
+- Add user accounts.
+- Add hosted execution.
+- Change JSONL schema.
+- Add `entryId` or `routeId` to daemon events.
+
+## Contract
+
+Relay durable state:
+
+- device identity metadata
+- client/Entry identity metadata
+- authorization bindings: `deviceId -> clientId`
+
+Relay transient state:
+
+- pair sessions
+- online presence
+- socket routing
+
+Relay forbidden state:
+
+- Project Registry
+- Session JSONL
+- prompts
+- tool results
+- provider responses
+- replay / resync cache
+- Runtime diagnostics that include user content
+
+Transport contract:
+
+```text
+Direct:
+  DaemonClient -> WsTransport -> Host
+
+Relay:
+  DaemonClient -> RelayTransport -> Relay -> Host relay adapter -> Host
+```
+
+`clientId` remains the daemon protocol and JSONL field for the Entry that authored user actions. Relay docs may use Entry as a product concept, but V1 does not introduce a separate `entryId` field.
+
+## Acceptance Criteria
+
+- `docs/spec/relay.md` defines Relay roles, state boundaries, pairing, routing, WebUI multi-device model, and reconnect semantics.
+- ADR-007 explains why Relay is proxy + authorization registry instead of hosted daemon.
+- Relay directory layout is explicit and does not introduce a top-level `relay/` directory or premature `packages/relay`.
+- S0057-S0060 exist and split M8 into Relay service skeleton, Host outbound pairing, Entry/WebUI connector, and real e2e validation.
+- `docs/ROADMAP.md` makes Relay + Hosted WebUI the next M stage.
+- `docs/architecture.md` points to the Relay spec and does not imply Relay owns Scorel domain state.
+- `docs/spec/client.md` describes `RelayTransport` as a transport adapter over the existing `DaemonTransport` contract.
+- `docs/README.md` links the new Relay spec and ADR.
+
+## Test Requirements
+
+Docs-only spec. Verification is document consistency:
+
+- grep for Relay references across docs.
+- inspect changed docs for conflicting `entryId` / `clientId` semantics.
+- no code tests required.
+
+## Affected Paths
+
+- `docs/spec/relay.md`
+- `docs/decisions/007-relay-proxy-and-entry-routing.md`
+- `docs/spec/ship/S0056-relay-and-hosted-webui-contract.md`
+- `docs/architecture.md`
+- `docs/spec/client.md`
+- `docs/ROADMAP.md`
+- `docs/README.md`
+- `docs/spec/ship/S0057-relay-service-protocol-skeleton.md`
+- `docs/spec/ship/S0058-host-outbound-relay-and-pair-command.md`
+- `docs/spec/ship/S0059-relay-transport-and-hosted-webui-connector.md`
+- `docs/spec/ship/S0060-relay-hosted-webui-e2e-validation.md`
+
+## Risks
+
+- Over-expanding Relay into a cloud backend would dilute Scorel's Host authority model.
+- Treating Relay as just a URL alias would miss authorization, multi-device routing, and hosted WebUI requirements.
+- Introducing new identity fields too early would churn JSONL and daemon protocol without product value.