Панель владельца swarm

I’m treating this as a planning-only task inside `dc-swarm`: first I’m locating the task workspace conventions and any existing planner/run-session flow, then I’ll create the child plan artifacts directly in-repo.

I found a task workspace already scaffolded under `tasks/` for this exact title, but it’s untracked and there are unrelated local changes elsewhere. I’m reading the task files and the repo’s task/session conventions now so I can either complete that scaffold safely or call out a real blocker if the format is inconsistent.

The task workspace is already populated, but it’s a stale 2026-05-17 seed. I’m checking the repo’s own naming and seed conventions before I refresh it to a current 2026-05-18 planner package instead of handing you yesterday’s session id.

The repo confirms the intended pattern: automation runs are child sessions, and planner output can stay local in `tasks/` without touching the live gateway store. I’m tightening this package so it reflects the current 2026-05-18 planner pass and references the real daily-loop template/runtime context instead of only yesterday’s placeholder.

I’ve confirmed the built-in template behind this task is `daily-social-analytics-loop`, with a real child-session model and publish-gated tail step. I’m now refreshing the seed package so the owner sees a current plan plus a child-run seed that maps cleanly onto the repo’s automation/session concepts instead of a loose checklist.

I have enough context. I’m updating the task workspace now: refresh the seed to today’s run id, make the child-session seed more machine-readable, and keep the result isolated to these task files without touching the live preview store.

The patch failed because the README is stored as numbered text, not plain headings. I’m re-reading the raw task files and will patch against their exact contents instead of assuming standard markdown formatting.

The planner package is rewritten. I’m verifying the JSON and spot-checking the seeded workspace now so the result is reviewable as-is and not just patched blindly.

`jq` isn’t installed here, so I’m validating the JSON with Node and checking for stale 2026-05-17 references in the seeded package. After that I can mark the workspace verification complete.

The planner package is in place under [daily-social-analytics-loop-plan.README.md](/home/admin/workspace/dc-swarm/tasks/daily-social-analytics-loop-plan.README.md:1), with the machine-readable plan in [daily-social-analytics-loop-plan.plan.json](/home/admin/workspace/dc-swarm/tasks/daily-social-analytics-loop-plan.plan.json:1) and the child-session seed in [daily-social-analytics-loop-plan.child-run-session.seed.json](/home/admin/workspace/dc-swarm/tasks/daily-social-analytics-loop-plan.child-run-session.seed.json:1). It seeds child run `child-run-qa-live-check-2026-05-18`, three ordered child tasks (`qa-live-01` bootstrap, `qa-live-02` smoke, `qa-live-03` verdict), and three review artifacts for brief, evidence, and final verdict. I validated both JSON files with Node and kept the result isolated to `tasks/` only. Explicit limitation: this planner pass does not mutate the live preview gateway store, so `automationParentSessionId`, `automationScheduleId`, `automationScheduledFor`, and `cycleKey` are intentionally left unresolved until a runner claims the real child session.