aming-claw-hn-demo

REQUIRED FIRST READ

Before any response that uses this skill, in this exact order:

ListMcpResourcesTool() ReadMcpResourceTool(uri="aming-claw://current-context") ReadMcpResourceTool(uri="aming-claw://skill") ReadMcpResourceTool(uri="aming-claw://graph-first")

current-context anchors project_id, governance URLs, and 3 guardrails. skill is the operating contract (Start Sequence, Observer Operating Modes). graph-first has copy-pasteable graph_query payload examples.

Common failures when these are skipped:

• Bootstrapping the wrong project (workspace_match auto-detected aming-claw)
• Calling task_create dev/pm (V1 default is observer-led mf_parallel.v1)
• Using Grep on the aming-claw codebase instead of graph_query
• Fabricating trace_id strings (audit ledger is server-resolvable, will fail)
• Running Execution Supervisor mode by default (Design Alignment is default)

Aming Claw HN Multi-Agent Challenge Demo

Run this as a guided operator flow, not a mandatory replay engine. Prefer deterministic dashboard, MCP, git, and fixture evidence. Do not require a live AI provider for the demo.

Guardrails

Role + Mode + Acceptance

• Role: the AI session is the observer-mode demo operator for the HN demo umbrella skill loaded by the Skill tool. The human reviews dashboard output and audit evidence. Do not look up or invent aming-claw://skill-hn-demo; use MCP resources only for the real runtime, graph, backlog, and evidence calls listed in REQUIRED FIRST READ.

• Live AI observer mode (preferred installed-user path): the observer is the current Claude Code or Codex session following this skill step by step. Do not claim that e2e-hn-demo.mjs --observer claude or --observer codex launches that AI runtime; in the runner, --observer is only a report label unless a separate install-audit container invokes the AI CLI and produces its own transcript/report. Use the scripted runner only for fixture setup, deterministic protocol smoke, screenshots, or final machine verification.

• Fixture mode: --ensure-fixture --no-browser provides only a bootstrapped aming-claw-hn-demo project, an active graph, and an empty backlog. It must not seed demo backlog rows, timeline rows, contracts, or fabricated graph-query trace ids.

• Sandbox audit mode: --sandbox-audit --no-browser is the repeatable launch gate. It creates a run-specific isolated fixture, runs install/package smoke checks, drives the multi-agent challenge through real governance calls, and writes docs/hn-demo/audits/latest.md plus latest.json. This is release/CI machine verification, not the preferred installed-user path. Add --browser only when screenshots are part of the review.

• Docker install audit mode: for true one-click install E2E, first run docker/hn-install-audit/run-install-audit.sh --host both. That produces separate Codex and Claude Code install reports from fresh container HOME directories with host auth mounted read-only. Pass those reports back to --sandbox-audit --require-install-gates; local package smoke alone is only preflight evidence, not an install PASS.

• Evidence mode: the AI observer-mode operator produces the demo contract, backlog rows, timeline events, graph-query trace evidence, and evidence summaries through real MCP calls against governance. Screenshots and dashboard links are references to that server-verifiable evidence.

• Mode boundary: Design Alignment is the default. Execution Supervisor mode is allowed only after an explicit operator/user decision to populate or supervise demo evidence; chain task_create dev/test/qa/merge remains out of scope for the HN demo.

• Setup acceptance: after fixture setup, prove the project graph exists and the backlog/timeline start empty, then run a real backlog duplicate/overlap probe before creating or updating the demo backlog row. Record the exact governance response body, including count, bugs, and request_id, then create or inspect a backlog contract with target files, tests/docs, acceptance criteria, and file/worktree fence evidence.

• Parallel worker and replay acceptance: timeline, lane, dispatch/startup gate, replay, and evidence inspector claims come from real task_timeline_append, precheck, server-side parallel branch runtime allocation, and graph_query results. Populate at least two worker contexts with disjoint owned_files; a one-worker timeline is not sufficient evidence for the HN challenge. The launch demo must be replay-shaped: one worker passes, one worker fails or is interrupted, and a replay attempt passes from the same contract evidence with attempt_num, parent task/contract identity, owned files, fence token, graph-query trace ids, and verification result preserved. Local aming-claw mf dispatch-gate validates the payload; it does not by itself register the worker fence with governance. Before the first mf_subagent graph_query, create or verify each worker runtime context through /api/graph-governance/<pid>/parallel-branches/allocate with the worker's task_id, parent_task_id, fence_token, base_commit, target_head_commit, and merge_queue_id. Capture returned ids and trace ids exactly; never fabricate graph_query_trace_ids. Worker runtime is generic: Claude, Codex, scripted workers, or any compatible local process can produce the evidence. The current session remains the observer; scripted workers are bounded worker runtimes or machine-verification fallbacks so users do not need two AI subscriptions. If mf_timeline_precheck reports mf_type=chain_rescue, describe it as the MVP MF storage bucket, not a chain requirement.

• Reconcile and review acceptance: accepted work reconciles once against the target graph, graph status and operations queue evidence are captured, and the generated audit report explains why the same observer trusts or hesitates on the run. Candidate or weak path evidence must stay untrusted until accepted by the review boundary or source-controlled hint.

• Do not silently start services. If governance is offline, tell the user to run aming-claw start in a separate terminal.

• Use governance on http://127.0.0.1:40000; the dashboard is http://127.0.0.1:40000/dashboard.

• Check or ask for the target project_id before using project-scoped dashboard links. If no target project exists and the user asked to run or preview the HN demo, use the isolated demo fixture path below instead of asking the user to invent a project id.

• Do not mutate a user's real project by default. Use read-only evidence unless the user explicitly asks for a governed action.

• Creating the isolated HN demo fixture is allowed for this skill: it writes a generated project under the OS temp directory, bootstraps that fixture through governance, and leaves the user's active app untouched.

• If browser automation is available, open the dashboard and capture screenshots of the challenge surfaces: graph, backlog timeline, operations, review, and audit report. Otherwise provide exact links and ask the user to capture screenshots.

• Treat screenshots as evidence references: record filename, view, project id, and what claim the screenshot supports.

Operator Flow

1. Baseline runtime:
   • Check runtime_status, graph_status, and graph_operations_queue when MCP is available.
   • If MCP is unavailable, check GET /api/health and provide the dashboard link; say MCP is not loaded in this session.
   • If dashboard assets are missing, say the demo cannot show dashboard evidence until assets exist or the dashboard build runs.
   • If /api/projects is empty, or the user has not selected a real project, run node frontend/dashboard/scripts/e2e-hn-demo.mjs --ensure-fixture --no-browser from the Aming Claw plugin checkout or installed plugin payload. This helper is packaged with the plugin and does not require a dashboard npm install for the --no-browser path. It only creates the isolated project; this current session still has to produce the contract, timeline, worker, replay, reconcile, and report evidence. Use the returned project_id="aming-claw-hn-demo" for dashboard links.
   • If the user asks whether the demo is ready for HN/public launch, run node frontend/dashboard/scripts/e2e-hn-demo.mjs --sandbox-audit --no-browser as release/CI machine verification, not as the preferred installed-user demo. Treat the generated Same-Observer Self-Review as machine-audit evidence only; a live user-facing claim should still come from the current observer session or explicitly say it is scripted.
   • If the user asks whether one-click install works for Codex and Claude, run docker/hn-install-audit/run-install-audit.sh --host both first, then rerun --sandbox-audit with the two generated --codex-install-report and --claude-install-report paths plus --require-install-gates.
2. Run the multi-agent challenge:
   • Prove the fixture has an active commit-bound graph and an empty backlog/timeline before evidence creation.
   • Create or inspect one backlog row with an mf_parallel.v1 contract for at least two disjoint workers.
   • Allocate or verify per-worker runtime contexts and fence tokens before any mf_subagent graph query.
   • Record Worker A passing, Worker B failing or being interrupted, and Worker B replay passing from the same contract lineage and frozen commit.
   • Capture real graph trace ids, test output, ordered merge/reconcile evidence, and close/precheck status.
   • Write or point to the generated audit report and quote the same-observer evaluation.
3. Collect the evidence index:
   • dashboard or MCP views inspected;
   • graph trace ids and whether they resolve;
   • worker task ids, fences, owned files, and replay lineage;
   • tests and reconcile evidence;
   • screenshots or dashboard links;
   • limitations, such as offline services, missing install-gate reports, or no live AI provider.
4. Optional: if the user explicitly asks for the older before/during/after story, use the supporting sub-skills aming-claw-hn-demo-before-work, aming-claw-hn-demo-during-work, and aming-claw-hn-demo-after-work.
5. End with a compact evidence index.

Suggested Dashboard Links

Use these with project_id=<id> when known:

• Projects: /dashboard?project_id=<id>&view=projects
• Graph: /dashboard?project_id=<id>&view=graph
• Backlog: /dashboard?project_id=<id>&view=backlog
• Operations Queue: /dashboard?project_id=<id>&view=operations
• Review Queue: /dashboard?project_id=<id>&view=review
• Asset Inbox: /dashboard?project_id=<id>&view=assets

If a view slug differs in the current dashboard, navigate from the dashboard sidebar and record the actual URL.

Evidence Summary

HN demo evidence
- Runtime: governance=<ok/offline>, dashboard=<ok/missing>, MCP=<ok/missing>, project_id=<id>
- Graph: snapshot=<id>, graph=<link/screenshot>, result=<claim>
- Workers: A=<pass evidence>, B=<failed/interrupted evidence>, replay=<pass evidence>
- Timeline: backlog=<link/screenshot>, lanes=<link/screenshot>, trace_ids=<resolvable ids>
- Merge/reconcile: commit=<sha>, operations=<link/screenshot>, result=<claim>
- Audit report: path=<latest.md/report>, same_observer_score=<score>, hesitation=<reason>
- Limitations: <offline services, missing fixture, manual screenshots, no live AI provider needed>