Mstar Host

Morning Star Host Adapter

Host-specific capabilities and entry behavior for Morning Star. Process gates and invariants stay in mstar-harness-core and topic mstar-* skills.

Load order

本 skill 总是在 mstar-harness-core 之后加载（先 Read mstar-harness-core SKILL.md；宿主注入项目 AGENTS.md 也不跳过，见下 ## First action）。本 skill 只适配宿主入口 / 检测 / 计划 UX；状态机与门禁以 mstar-harness-core 为准。

First action

Read mstar-harness-core before this skill (even when the host injects project AGENTS.md).

Default path

1. Read mstar-harness-core
2. Read mstar-host (this skill) and detect host below
3. Read references/<host>.md for the active host
4. Load role via mstar-roles
5. Execute with evidence-first completion checks

Load topic skills on demand per mstar-roles (do not read every mstar-* skill by default). Cursor routing-eval (.cursor/skills/mstar-routing-eval/) is regression tooling only — not part of runtime load order.

Detect active host

Detect from session tool shapes and available commands — not from plugin markers on disk. The *-plugin/plugin.json files cannot identify the host: they all coexist in this harness source repo and in any multi-host install.

Order matters: check cursor → opencode → omp → dsh → kimi → zcode → codex. The four Task-shaped tokens are distinct: subagent_type (Cursor), task_subagent (OpenCode's subagent parameter on the task tool), agent/tasks[] (omp), and subagent (dsh's own delegation tool). No row shares another's token, so the dsh row collides with none and sits with the agent-tool hosts.

Engine check (when available): run mstar host detect --signals <comma-list> (or import { detectHost } from "@mstar-harness/engine" in a host hook) to resolve the detection table above from session tool shapes (prints the host id, or ambiguous to fall back on the table + judgment). On fail -> do not proceed; fix and re-run. Skill text below remains authoritative when the runtime is absent.

Parallel dispatch (invoke-capable hosts)

When PM dispatches N >= 2 concurrent assignees (QC tri-review, dual-track implement, etc.) and the host exposes actual invoke / Task / subagent tools, read references/parallel-dispatch.md in the dispatch round (shared with mstar-dispatch-gates). Without a callable invoke tool when dispatch is required → Blocked; Assignment Markdown alone is not dispatch.

On dsh only, read-only fan-out runs through the native workflow tool instead of N subagent invokes. N ≥ 3 is the width it is designed for; 1–2 seats are carried by subagent — read-only fan-out never takes a teammate at any N. Where the Team layer disables subagent, the script follows the work, not the seat count: a 2-seat PR review runs § 3 mstar-pr-seats with the tier's two domain lenses, and a 2-category codebase audit runs § 2 mstar-audit-fanout with two categories (§ 3 requires target + diffBase, so it never carries an audit). Separately, a one-seat SDD task review must not consume a roster slot, so routing it through a one-seat § 4 workflow run is a supported route on a Team profile, not an improvisation. Writable fan-out never uses workflow — it has no per-child pre-start veto seam. Scripts + operator path: references/dsh.md § Read-only fan-out via the workflow tool.

/goal directive (host-agnostic)

Applicability is by capability, not host identity: any host that exposes a /goal command (currently Codex Goal Mode and omp; other code agents may add it later) attaches a persistent objective to the thread. Exception — dsh: mstar stops arming a goal there and never uses a /goal objective or a goal round loop as the progression driver — dsh runs on the native workflow (workflow snapshot phases + dispatch gates + subagent settle notifications; each settle notification is a result-settled Rescheduling checkpoint — run that checkpoint and dispatch the ready independent work before any wait, never "one settle → one dispatch", per mstar-iteration references/phase-2-worktree-lease.md §2.4; a manually armed /goal stays outside mstar's flow). Full rule → references/dsh.md. Rule — always set the goal to running the complete flow to the end, never a sub-stage:

• Advancing an iteration: set the goal to complete the entire iteration flow (iteration-start → per-plan cycles → iteration-close → PR delivery → PR merge-ready loop). Do not set a sub-stage goal (e.g. "finish Phase 1 only").
• Advancing non-iteration work (single plan / hotfix / one-off task): set the goal to complete the entire per-plan flow (specify → clarify → plan → tasks → implement → plan QC tri + QA gate → Done; standalone development plans continue through the delivery tail to verified merge + terminal close — mstar-harness-core「最小交付循环」/ mstar-artifacts/references/plan-workflow-lifecycle-contract.md). Do not set a sub-stage goal (e.g. "write the plan" or "implement one task").

Goal text is a session-level objective only: store.db execution authority under {HARNESS_DIR} and authored {PLAN_DIR} plans remain authoritative, and goal completion is not harness Done. Mirror goal success criteria into the SSOT plan; when the goal changes, update goal text and the SSOT in the same round.

Phase-transition todo refresh (host-agnostic)

At each phase transition the primary PM refreshes session todos before the next action/dispatch: close completed entries only, retain pending gates and append next-phase obligations. Project the selected workflow's complete lifecycle, not another per-row primary scope. Todos remain a projection, not state authority.

todo entries are a projection, not SSOT: they reflect the ACTIVE workflow phase / plan states and named plan/gate evidence, and cannot authorize or invent a state transition. Store.db workflow/plan rows remain the execution authority, with authored plan artifacts kept aligned; this is freshness discipline, not a new host hook anchor, tool, or deterministic enforcement mechanism.

Host hooks (anchor contract)

Shared lifecycle skills name host-agnostic anchors — named moments at which the active host obliges the PM to run a host-defined coordinator action. The anchor vocabulary is frozen and carries no host identity: tool names, exact parameters, prerequisites, refusal codes, native settings and auto-trigger scope live only in references/<host>.md.

Execution rule. At each anchor the PM executes whatever the active host reference declares under its own ## Host hooks section for that anchor. A host reference that declares nothing for an anchor means no-op: never invent an action, never substitute another host's declaration, and never treat an absent declaration as permission to skip the anchor's shared step.

Marker form. A shared file that owns an anchor carries a comment marker plus a one-line pointer — neither names a host or a tool:

markdownCopy code
<!-- host-hook: <anchor> -->
> Execute the active host reference's `## Host hooks` declaration for `<anchor>`; this file defines no host action.

Carrier locations — the four markers in the shared corpus (all four live under skills/, never in commands/):

Shared-text boundary: new/modified skills outside mstar-host and canonical commands use capability wording, not host names/tools/fields/native settings/extension filenames. Concrete adapters remain exclusively in this skill's per-host references.

Exception — an authorized optional-capability reference. A reference may carry the concrete adapter (host names, command surface, error codes) of an optional capability when the feature is defined by that external capability itself, provided it: (a) names the loaded external skill as the sole authority for the command surface and lifecycle, and defers to it on any difference; (b) keeps the adapter in its own owner file rather than spreading those tokens into any other shared text; and (c) leaves the default path complete without the capability, with a plain fallback for every failed gate leg. This exception narrows nothing else in this section.

Enforcement surface. The check applies to the files a change touches, never to the whole corpus: shared text that already violates the rule and is not part of the current change is out of scope of the rule's enforcement and is cleared in batches under the host-seam-corpus-cleanup goal of the store-authoritative _default project roadmap (read rule → mstar-project-governance; legacy {PROJECT_DIR}/_default/roadmap.md is transport/history only). Until that cleanup completes, a whole-tree grep over shared text is not a valid assertion for this rule — judge a change on the shared-layer text it adds or edits.

Resolve loaded skill root

Docs name assets as skill <name> → scripts/… / references/…. Resolve the loaded skill directory first — do not open skills/<name>/… from a consumer app cwd (that layout exists in the harness source / plugin package only).

Authoring convention: mstar-skill-authoring § Skill-relative script and asset paths. Per-host URI / mount detail: references/<host>.md.

Engine check (when available): run mstar host skill-root --host <id> --skill <name> (or import resolveSkillRoot from @mstar-harness/engine in a host hook) to resolve the loaded skill root per the table above. On fail -> do not proceed; fix and re-run. Skill text below remains authoritative when the runtime is absent.

Conflict order（Decision Rules）

1. User explicit instructions (this turn)
2. Project AGENTS.md / CLAUDE.md
3. mstar-harness-core and related mstar-* skills
4. This mstar-host skill and references/*

Workflow

按 ## Default path 执行：Read mstar-harness-core → 读本 skill 并按 ## Detect active host 检测宿主（cursor → opencode → omp → dsh → kimi → zcode → codex）→ 读 references/<host>.md（计划模式另读对应 plan-mode bridge）→ 经 mstar-roles 加载角色 → 执行并以证据收尾。topic skill 按需加载，不默认通读。

Evidence

正确结果 = 检测输出：mstar host detect --signals <comma-list> 打印 host: <id>（或 ambiguous → 按检测表 + 判断降级）；已加载的是对应当前宿主工具形状的 references/<host>.md。计划模式按宿主 plan-mode bridge 完成双写 / 对齐。

For iteration Phase 1, use the shared bridge's prototype-first exception to early formal dual-write: preserve one session carrier, separate current-design approval from implementation permission, and use documented host permission recovery for restricted package writes/invoke. Procedure authority → mstar-iteration/references/phase-1-prepare.md §1.2.5 / §1.6; host limits/recovery → references/_shared/plan-mode-bridge-core.md + active host bridge.

References

• 各宿主适配细则 → references/<host>.md（cursor / opencode / omp / dsh / kimi / zcode / codex；计划模式另见 plan-mode bridge references）
• invoke-capable 宿主并行派发 → references/parallel-dispatch.md
• 角色加载与参数 → mstar-roles