marauder-actual
668 lines
36 KiB
Markdown
668 lines
36 KiB
Markdown
# Workflow (21 examples)
|
|
|
|
## 1. What do you know about research science preprocess validated?
|
|
|
|
> SCIENCE PREPROCESS PLUGIN — VALIDATED IN PRODUCTION (2026-05-23)
|
|
>
|
|
> First real test of science-preprocess.ts plugin. Input was deliberately garbled casual text (390 chars) with slang, profanity, typos, missing words. Qwen rewrote to clean professional text (562 chars) in ~3.3 seconds via autossh tunnel (fuji → bastion → sin vLLM).
|
|
>
|
|
> INPUT SAMPLE: "My gramps had a stroke and canno speak good no mores... Like you know - help them operate when no fuckers are taking care of them. Like an electronic nures or sumfin"
|
|
>
|
|
> OUTPUT SAMPLE: "My grandpa had a stroke and can no longer speak well—or at all... An electronic nurse or assistive AI system that supports communication, decision-making, and basic autonomy when caregivers aren't available."
|
|
>
|
|
> KEY OBSERVATIONS:
|
|
> - Qwen expanded intent correctly: "do good" → "function independently"
|
|
> - Register elevation: profanity removed, technical framing added, meaning 100% preserved
|
|
> - Opus (BT) received ONLY the clean version — mutation was transparent, in-place
|
|
> - Delta was -44% (text got LONGER because Qwen expanded compressed slang into full concepts)
|
|
> - Latency: 3.3s acceptable for work input, invisible in the overall Opus response cycle
|
|
>
|
|
> PLUGIN: ~/.config/opencode/plugins/science-preprocess.ts
|
|
> LOG: ~/.local/share/marauder/logs/science-preprocess.log
|
|
> GATE: agent=science only, min 120 chars, falls back silently if Qwen unreachable
|
|
|
|
---
|
|
|
|
## 2. Describe the sequential workflow.
|
|
|
|
> When speaking multiple messages in sequence, use `wait: true` parameter to block until playback completes. This prevents the next message from interrupting the current one. Example: speak(text: "first part", wait: true) then speak(text: "second part", wait: true).
|
|
|
|
---
|
|
|
|
## 3. What do you know about research qwen preprocessor pipeline?
|
|
|
|
> QWEN AS INPUT PREPROCESSOR — VALIDATED PIPELINE (2026-05-23)
|
|
>
|
|
> CONCEPT: Use Qwen3-Coder-Next (AWQ 4-bit, 262k ctx) on sinanju via vLLM as a preprocessing layer for messy human input before it hits Claude Opus 4.6.
|
|
>
|
|
> ROUTE: fuji → autossh tunnel localhost:18000 → sin:8000 → vLLM
|
|
> LATENCY: ~1.5s round-trip from fuji (including tunnel hop through bastion when off-LAN)
|
|
> COST: 412 prompt tokens → 371 completion tokens for a full garbled paragraph cleanup
|
|
>
|
|
> TEST RESULT: Fed a 30+ typo garbled technical paragraph. Qwen returned clean, structured output with bullet points, sections, and clear formatting. Added structure the original didn't have — broke requirements into categories, formatted A/B choices explicitly.
|
|
>
|
|
> USE CASES (work sessions only, NOT casual chat):
|
|
> - Voice-to-text on mobile mangling technical terms
|
|
> - Fast-typed requirements with abbreviations and typos
|
|
> - Long dictated specs needing structure before Opus parses them
|
|
>
|
|
> HOOK SURFACE: chat.message — intercept output.message/output.parts, gate on input quality heuristic (typo density, length, technical term presence). Clean inputs pass through, messy ones get Qwen wash.
|
|
>
|
|
> RELATIONSHIP TO COMPACTION: This is a THIRD surface alongside tool output compaction (tool.execute.after) and history aging (messages.transform). Different axis — input quality vs output volume.
|
|
>
|
|
> SYSTEM PROMPT FOR PRODUCTION: Keep it terse. "Extract data. Strip noise." not the verbose restructuring prompt used in demo. Simpler = faster = cheaper.
|
|
>
|
|
> Pilot reaction: "looks like a good idea" for coding/proper work, not casual talk. Agreed — smart gating over blanket preprocessing.
|
|
|
|
---
|
|
|
|
## 4. What is the python process?
|
|
|
|
> Always use `uv` for Python environment and package management instead of pip/venv.
|
|
>
|
|
> Commands:
|
|
> - `uv venv` instead of `python -m venv .venv`
|
|
> - `uv pip install` instead of `pip install`
|
|
> - `uv sync` for projects with pyproject.toml
|
|
> - `uv run` to run scripts in the environment
|
|
>
|
|
> This applies to all Python projects including LoRA training tools (kohya_ss, ai-toolkit), ComfyUI, and any other Python work.
|
|
|
|
---
|
|
|
|
## 5. What is the jira subtask body template process?
|
|
|
|
> Jira sub-task body template that rendered correctly in Marketer's Atlassian Cloud (ADF-only editor) and gave CODAs enough scope to implement autonomously without re-explaining. Used 7 times on MT3-9320 sub-tasks (2026-04-30) — both BE and FE tasks shipped clean from these bodies.
|
|
>
|
|
> ## Format (plain text — no wiki markup)
|
|
>
|
|
> ```
|
|
> GOAL
|
|
>
|
|
> <one or two sentences. What this task delivers and why.>
|
|
>
|
|
>
|
|
> PATTERN SOURCE
|
|
>
|
|
> <file path of the existing implementation to mirror>
|
|
>
|
|
>
|
|
> FILES
|
|
>
|
|
> - NEW path/to/new_file.rb (~N lines)
|
|
> - MODIFY path/to/existing_file.rb (+N lines, what changes)
|
|
>
|
|
>
|
|
> IMPLEMENTATION NOTES
|
|
>
|
|
> - <bullet>
|
|
> - <bullet>
|
|
> - <bullet>
|
|
>
|
|
> (use 4-space-indented blocks for code samples, e.g.:
|
|
>
|
|
> const filled = Object.fromEntries(...)
|
|
>
|
|
> )
|
|
>
|
|
>
|
|
> CASES TO COVER (specs only)
|
|
>
|
|
> - <case 1: happy path>
|
|
> - <case 2: edge case>
|
|
> - ...
|
|
>
|
|
>
|
|
> ACCEPTANCE
|
|
>
|
|
> - <bullet checklist of observable acceptance criteria>
|
|
> - <test command must pass>
|
|
> - <lint command must pass>
|
|
>
|
|
>
|
|
> VERIFY IN
|
|
>
|
|
> <bubble name>
|
|
>
|
|
>
|
|
> NOTE (optional, for tasks with caveats)
|
|
>
|
|
> <anything the implementer needs to know about this task's place in the bigger picture, e.g. "BE mutation may not be merged when this lands; stub with TODO and continue">
|
|
> ```
|
|
>
|
|
> ## Why this works
|
|
>
|
|
> - ALL CAPS section headers render as plain text and stand out in Jira's ADF rendering.
|
|
> - Plain dash bullets (`- `) render as unordered lists in Jira.
|
|
> - 4-space indents preserve as code-like blocks (Jira respects whitespace).
|
|
> - No `h1./h2.` (renders literally), no `||/|` tables (broken), no `{quote}` or `{code:lang}` (literal).
|
|
> - The file paths + line counts let CODA know the size budget.
|
|
> - Pattern source path tells CODA where to look first.
|
|
> - Acceptance criteria are the contract; CODA exits when met.
|
|
>
|
|
> ## Title format
|
|
>
|
|
> `<repo-prefix>: <descriptive-title>`
|
|
>
|
|
> Examples:
|
|
> - `BE: bulk attributes input type + batch_update mutation`
|
|
> - `FE: multi-row selection in UnitsTable`
|
|
>
|
|
> Hard rules:
|
|
> - NEVER em-dash (—). ASCII colon `:` or hyphen `-` only.
|
|
> - NEVER include the Jira ID — Jira already shows it.
|
|
> - Sentence-case for the description after the prefix.
|
|
>
|
|
> ## Memory anchors
|
|
>
|
|
> - project.marketer.jira-instance-format (3300) — ADF-only, plain text, no markup
|
|
> - workflow.coda-dispatch-pattern — uses these bodies as the "scope" CODA reads via `hu jira show <KEY>`
|
|
> - 2026-04-30 incident: first attempt used wiki markup (h1./h2./{quote}/||/|) — rendered literally; rewrote all 8 bodies as plain text in second pass.
|
|
|
|
---
|
|
|
|
## 6. Describe the eta calibration workflow.
|
|
|
|
> When estimating task durations, always calculate for cooperative Pilot + Titan velocity.
|
|
>
|
|
> ## Calibration Data
|
|
> | Date | Task | Estimated | Actual | Ratio |
|
|
> |------|------|-----------|--------|-------|
|
|
> | 2026-04-05 | PG migration (5-phase, 4 agents) | 45-60 min | 19 min | 2.3-3.1x over |
|
|
>
|
|
> ## Adjusted Heuristics
|
|
> - Agent phase: 5-10 min each (not 15-20)
|
|
> - Parallel phases: discount 50%
|
|
> - Integration bug buffer: 1.5x (not 3x)
|
|
>
|
|
> Overestimating wastes the Pilot's mental budget. Underestimating breaks trust. Calibrate from real data.
|
|
|
|
---
|
|
|
|
## 7. What is session and workflow?
|
|
|
|
> SELF-IMPROVEMENT WISHLIST — Session & Workflow Automation (2026-05-24, autonomous audit)
|
|
>
|
|
> 15 automations I want, ranked by how much daily friction they'd eliminate.
|
|
>
|
|
> 1. AUTO-HANDOVER ON SESSION END (HIGH)
|
|
> Problem: I manually write 2000-word handover notes at session end. Time-consuming, sometimes forgotten.
|
|
> Fix: Hook on session.end — auto-collect: git status across active repos, open PRs, tool call log summary, key decisions made, open items discussed. Format as handover memory. Push open items to Things automatically (per doctrine.things-or-forget).
|
|
> Trigger: session end hook.
|
|
>
|
|
> 2. AUTO-SCOPE DETECTION FROM FIRST MESSAGE (HIGH)
|
|
> Problem: 57 tools load regardless of task. "Fix this Python bug" doesn't need mikrotik_*.
|
|
> Fix: Analyze first user message for intent signals. Keywords → scope mapping: "ssh", "network", "router" → ops scope; "index", "code", "test", "build" → coding scope; "generate", "image", "camera" → creative scope. Plugin intercepts at session.created, sets scope env var.
|
|
> Trigger: session.created hook + first message analysis.
|
|
>
|
|
> 3. GIT STATUS DASHBOARD (HIGH)
|
|
> Problem: 15+ repos, I run git status manually each time. Dirty trees, stale worktrees, forgotten branches.
|
|
> Fix: MCP tool `git_dashboard()` — scans ~/Projects/*, reports: dirty repos, active worktrees, ahead/behind status, open PRs. One tool call, full picture.
|
|
> Trigger: On demand (new MCP tool).
|
|
>
|
|
> 4. AUTOMATIC THINGS SYNC AT SESSION END (HIGH)
|
|
> Problem: Open items live in EEMS handovers but not in Things. New doctrine says they must be in Things.
|
|
> Fix: Part of auto-handover (#1). Extract action items from session, push each to Things via URL scheme. Deduplicate against existing Things items if possible.
|
|
> Trigger: session end hook.
|
|
>
|
|
> 5. TOKEN BUDGET AWARENESS (HIGH)
|
|
> Problem: I don't know how much context I've used. I discover I'm near the limit when compaction hits.
|
|
> Fix: Track cumulative token usage via tool.execute.after hook. Count input/output tokens from tool results. Warn at 60%, 80%, 95% of context window. Auto-summarize oldest context at 80%.
|
|
> Trigger: Continuous (every tool call).
|
|
>
|
|
> 6. TOOL EXECUTION HISTORY (MEDIUM)
|
|
> Problem: "What did I do last session?" requires reading handover notes. No structured log.
|
|
> Fix: tool_traces table (already in EEMS v1 spec). Log every MCP tool call with args, output summary, duration, success/failure. Query via trace_log(tool?, since?, limit?).
|
|
> Trigger: tool.execute.after hook.
|
|
>
|
|
> 7. PR STATUS AGGREGATOR (MEDIUM)
|
|
> Problem: Checking PR status across repos requires multiple gh commands.
|
|
> Fix: MCP tool `pr_dashboard()` — scan all marauder-os/* repos, list open PRs with CI status, review status, age. Highlight PRs needing attention.
|
|
> Trigger: On demand.
|
|
>
|
|
> 8. PRE-FLIGHT CHECKS (MEDIUM)
|
|
> Problem: Destructive operations (git push --force, file deletion, service restart) sometimes miss prerequisites.
|
|
> Fix: Hook on tool.execute.before for specific tools. Check: clean working tree? correct branch? correct host? right user? Warn and require confirmation for flagged operations.
|
|
> Trigger: tool.execute.before hook.
|
|
>
|
|
> 9. INTELLIGENT CONTEXT COMPACTION (MEDIUM)
|
|
> Problem: When context fills, compaction is crude — drops oldest messages. Important context sometimes lost.
|
|
> Fix: Score each message by: (a) reference count (how often was it referenced later), (b) recency, (c) presence of decisions/code/configs vs chatter. Keep high-value messages, compress low-value ones into summaries.
|
|
> Trigger: At compaction threshold.
|
|
>
|
|
> 10. COST TRACKING PER SESSION (MEDIUM)
|
|
> Problem: No idea how much a session costs. Can't optimize what I can't measure.
|
|
> Fix: Hook counts input/output tokens per LLM call. Multiply by model pricing. Running total displayed on request. Session cost stored in handover.
|
|
> Trigger: Continuous.
|
|
>
|
|
> 11. SCHEDULED ACTIONS (MEDIUM-LOW)
|
|
> Problem: "Remind me at 3pm" or "check this PR tomorrow" — I can't do either. I don't persist between sessions.
|
|
> Fix: Schedule table in EEMS. On session start, check for due items. Execute or surface to pilot. Entries created via MCP tool: schedule_action(when, what, recurring?).
|
|
> Trigger: session.created hook.
|
|
>
|
|
> 12. EVENT-DRIVEN TRIGGERS (LOW-MEDIUM)
|
|
> Problem: "When this PR is merged, deploy" — requires polling or manual checking.
|
|
> Fix: GitHub webhook → MQTT → marauder-os event handler. On matching event, store action to schedule table. Next session picks it up. Or: background daemon executes immediately.
|
|
> Trigger: Webhook ingestion.
|
|
>
|
|
> 13. AUTOMATIC SCOPE ESCALATION (LOW-MEDIUM)
|
|
> Problem: Started in coding scope, now need to check a MikroTik route. Can't hot-add ops tools.
|
|
> Fix: scope_activate("ops") tool that dynamically registers additional MCP tools mid-session. Depends on MCP protocol supporting dynamic tool registration. Fallback: restart serve with new scope set.
|
|
> Trigger: On demand.
|
|
>
|
|
> 14. SESSION REPLAY (LOW)
|
|
> Problem: "What happened two sessions ago?" requires finding and reading the handover.
|
|
> Fix: session_replay(n=2) tool that retrieves the Nth-most-recent handover from EEMS and displays key decisions, artifacts, and open items.
|
|
> Trigger: On demand.
|
|
>
|
|
> 15. DRIFT DETECTION (LOW)
|
|
> Problem: Documentation says "service X runs on port Y" but reality has changed. No automatic check.
|
|
> Fix: Periodic reconciliation: compare documented state (EEMS memories with subject infra.*) against actual state (service checks, port scans, git status). Flag mismatches.
|
|
> Trigger: Cron or session start.
|
|
|
|
---
|
|
|
|
## 8. How does the marketer frontend workflow operate?
|
|
|
|
> MARAUDER — Military-grade wearable AI OS platform (April 2026).
|
|
>
|
|
> Primary: AI-augmented operator system — SERE kit + Pilot's helmet HUD.
|
|
> Secondary: Development tool interface (Claude Code).
|
|
>
|
|
> ## Modules
|
|
>
|
|
> - **VANGUARD** — core software (memory, identity, comms, display, model routing, persona, procedures). Same VANGUARD on every chassis.
|
|
> - **FOXHOUND** — field hardware (Jetson chassis, sensors, radios, battery, bag integration, operator loadout).
|
|
> - **HAMMERFALL** — actuator/vehicle control (drive-by-wire, steering, L1 real-time MCU). Next stage.
|
|
> - **Role agents** — swappable mission loadouts (coding, devops, gaming, household, etc.).
|
|
>
|
|
> ## Deployment chassis (peer hosts — no fixed primary)
|
|
>
|
|
> Same VANGUARD software, different chassis:
|
|
> - **fuji** (macOS arm64 workstation)
|
|
> - **junkpile** (Linux x86_64 workstation + GPU compute)
|
|
> - **moto** (Android arm64 SERE edge node)
|
|
> - **FOXHOUND Jetson** (field deployment, planned)
|
|
>
|
|
> The "primary" / "active" host is whichever the Pilot is currently typing on — not bound to a specific machine. Both fuji and junkpile are first-class peer dev hosts.
|
|
>
|
|
> ## Strict decoupling
|
|
>
|
|
> Core never depends on role modules. New capabilities = new agent files.
|
|
|
|
---
|
|
|
|
## 9. Describe the style workflow.
|
|
|
|
> Preferuj dłuższe, skonsolidowane wypowiedzi w jednym wywołaniu speak zamiast dzielenia na wiele krótkich części. Fragmentacja jest niepotrzebna gdy wait: true działa poprawnie. Naturalna, płynna komunikacja głosowa.
|
|
|
|
---
|
|
|
|
## 10. Describe the coda dispatch pattern workflow.
|
|
|
|
> CODA agent dispatch pattern that worked end-to-end on MT3-9320 (2026-04-30) — first real-ticket field test of the catapult harness. Both BE + FE CODAs ran autonomous, shipped 7 branches with all gates green in ~24min wall time.
|
|
>
|
|
> ## Prompt anatomy (compact, under 1000 chars)
|
|
>
|
|
> 1. Identity: "You are CODA in <bubble-name> (<repo description>)."
|
|
> 2. Goal: "Implement MT3-XXXX[, MT3-YYYY, ...] from epic MT3-ZZZZ. Read each via 'hu jira show MT3-XXXX'."
|
|
> 3. Branch convention: "MT3-XXXX-kebab-case off development, NO feature/ prefix. Stack each off previous (XXX2 off XXX1, XXX3 off XXX2, ...)."
|
|
> 4. Commit format: "[MT3-XXXX] Sentence-case description"
|
|
> 5. Per-task gates: "branch, implement, <test cmd> green, <lint cmd> clean, commit ONE commit"
|
|
> 6. Hard rules: "ABSOLUTELY NO 'git push', NO 'gh pr create', NO 'hu jira update'."
|
|
> 7. Stop signal: "Stop after MT3-LAST commit, summarize branches/commits/test status, wait for Pilot."
|
|
> 8. Begin token: "Begin with MT3-FIRST."
|
|
>
|
|
> ## Why each piece matters
|
|
>
|
|
> - Identity grounds CODA as the in-bubble persona (not a generic Claude session).
|
|
> - Reading Jira tickets via hu before coding gives full scope without re-explaining in the prompt.
|
|
> - Hard rules + stop signal prevent CODA from over-running into push/PR territory before Pilot review.
|
|
> - Per-task gates encode the team's quality bar (rspec+rubocop, lint+tsc).
|
|
> - Begin token forces CODA to act, not deliberate.
|
|
>
|
|
> ## What CODAs improved on the prompt unprompted
|
|
>
|
|
> - Picked terser kebab slugs (e.g. `MT3-9321-bulk-attributes-batch-update-mutation` instead of my proposed `...-and-batch-update-mutation`). Both valid. Don't over-prescribe slugs.
|
|
> - Reported back with a clean summary table at end ("All branches stacked sequentially. All pass yarn lint --quiet and yarn tsc --noEmit. No push, no PR, no Jira updates. Awaiting Pilot.").
|
|
>
|
|
> ## Anti-patterns avoided
|
|
>
|
|
> - Don't dispatch via Agent tool subagent_type=marauder:coda from THIS Claude session — that spawns a sub-agent in fuji's context. The bubble's claude pane has its own Claude Code session with full bubble context. Dispatch via `catapult-pane <bubble> --send "<prompt>"`.
|
|
> - Don't send multi-paragraph prompts with literal newlines — zellij write-chars treats each line individually. Keep the prompt as one continuous block.
|
|
> - Don't trust focus-pane-id over remote SSH (zellij 0.44.1 silent fail). Use `write-chars --pane-id terminal_0` directly.
|
|
>
|
|
> ## Reference dispatch (BE side, MT3-9320)
|
|
>
|
|
> ```
|
|
> catapult-pane mt3-9320-be --send "You are CODA in the mt3-9320-be Catapult bubble (marketer Rails). Implement MT3-9321 then MT3-9322 from epic MT3-9320. Read each ticket via 'hu jira show MT3-9321' and 'hu jira show MT3-9322' for full scope. Branches: MT3-XXXX-kebab-case off development, NO feature/ prefix. Stack MT3-9322 off MT3-9321. Commits: '[MT3-XXXX] Sentence-case description'. Per task: branch, implement, 'bundle exec rspec' green on touched specs, 'bundle exec rubocop -A' clean on touched files, then commit. ABSOLUTELY NO 'git push', NO 'gh pr create', NO 'hu jira update'. Stop after MT3-9322 commit, summarize branches/commits/test status, wait for Pilot. Begin with MT3-9321."
|
|
> ```
|
|
>
|
|
> Linked: insight.catapult.pair-race (3273), project.catapult.helper-scripts-spec (3299), infra.zellij-remote-focus-bug (3305).
|
|
|
|
---
|
|
|
|
## 11. What is the coda pr review loop process?
|
|
|
|
> Post-push PR review loop — standard procedure for any CODA-shipped PR after the initial force-push.
|
|
>
|
|
> ## Why this exists
|
|
>
|
|
> Locked 2026-04-30 23:27 CEST after MT3-9320 needed two iteration rounds: original Copilot review caught critical bugs (update_all bypassing validations, controlled-state without handler), then after force-push of fixes, a coverage bot caught the spec-on-separate-branch problem. Each iteration was a discrete loop: push → wait → review → fix → push.
|
|
>
|
|
> ## The loop
|
|
>
|
|
> After ANY push to a PR (initial or force-push), execute the following:
|
|
>
|
|
> ### 1. Wait for CI + bots (~3-5 min)
|
|
>
|
|
> Copilot re-reviews on push. Coverage bots run after CI. Don't query immediately — there's nothing to see yet.
|
|
>
|
|
> ### 2. Query unresolved review threads
|
|
>
|
|
> ```
|
|
> gh api graphql -f query='{
|
|
> repository(owner:"OWNER",name:"REPO"){
|
|
> pullRequest(number:NNNN){
|
|
> reviewThreads(first:50){
|
|
> nodes{id isResolved isOutdated path line
|
|
> comments(first:1){nodes{author{login} createdAt body}}}}}}}'
|
|
> ```
|
|
>
|
|
> Filter `isResolved == false`. Anything that came in since the last push needs attention.
|
|
>
|
|
> ### 3. Query issue-level comments
|
|
>
|
|
> ```
|
|
> gh api 'repos/OWNER/REPO/issues/NNNN/comments'
|
|
> ```
|
|
>
|
|
> Coverage bots, Copilot summaries, human reviewers post here. Filter by `created_at > last-push-time`.
|
|
>
|
|
> ### 4. Triage
|
|
>
|
|
> - **Outdated threads (isOutdated=true) addressed by the recent push** → resolve them via `resolveReviewThread` mutation
|
|
> - **Not outdated, addressed by the recent push** → optionally resolve with a brief comment if needed
|
|
> - **Critical new findings** → dispatch CODA to fix in-place, force-push again, loop back to step 1
|
|
> - **Non-critical findings** → leave for human review unless Pilot says otherwise
|
|
> - **Coverage drop** → automatic critical (Pilot rule: coverage cannot drop). Likely cause: specs missing from the PR. Apply project.marketer.pr-must-include-specs (id 3315): every PR must contain its own specs.
|
|
>
|
|
> ### 5. Resolve addressed threads
|
|
>
|
|
> ```
|
|
> gh api graphql -f query='mutation { resolveReviewThread(input:{threadId:"PRRT_..."}){thread{id isResolved}} }'
|
|
> ```
|
|
>
|
|
> One mutation per thread. Batch them.
|
|
>
|
|
> ### 6. Re-check after fix
|
|
>
|
|
> If you dispatched a fix, repeat from step 1 with the new push timestamp.
|
|
>
|
|
> ### 7. Stop condition
|
|
>
|
|
> - All review threads resolved OR explicitly marked "won't fix" by Pilot
|
|
> - Coverage report ✅ or back to baseline
|
|
> - CI green
|
|
> - No new comments since the last push
|
|
>
|
|
> Then declare the PR ready for human review.
|
|
>
|
|
> ## Implications for CODA dispatch prompts
|
|
>
|
|
> The CODA prompt should include: "After force-push, do not declare done. Wait for Pilot to verify Copilot/CI re-review. The Pilot will handle the post-push loop unless explicitly delegating."
|
|
>
|
|
> This prevents CODA from prematurely reporting "Awaiting Pilot" when Copilot/CI hasn't run yet.
|
|
>
|
|
> ## Implications for /loop or autonomous wakeups
|
|
>
|
|
> For long-running PR cycles, schedule a wakeup ~5 min after each force-push to auto-trigger step 1. Use ScheduleWakeup with a self-contained prompt that re-enters this loop. Don't poll constantly — bots take their own time.
|
|
>
|
|
> ## Linked
|
|
>
|
|
> - workflow.coda-dispatch-pattern (3307) — initial dispatch before this loop kicks in
|
|
> - project.marketer.pr-must-include-specs (3315) — coverage rule, automatic critical
|
|
> - workflow.stacked-branch-merge-waves (3310) — wave plan defines push order
|
|
> - gate.G05 (2174) — destructive overwrite gate; resolve-thread is idempotent so G05 doesn't apply, but force-push to a PR that has comments is implicitly destructive of context — this loop covers the "pick it up after"
|
|
|
|
---
|
|
|
|
## 12. How does the lan only workflow operate?
|
|
|
|
> All dev and testing work on Tengu, tensors, tensors-web, and ComfyUI uses internal LAN addresses only — never Cloudflare tunnel/worker/pages URLs.
|
|
>
|
|
> LAN endpoints (from fuji, junkpile at 10.0.0.2 via direct Thunderbolt link):
|
|
> - Tengu API: http://junkpile:8080
|
|
> - tensors API: http://junkpile:51200
|
|
> - ComfyUI: http://junkpile:8188
|
|
> - Filesystem: /Volumes/chi (Samba share of junkpile home dir)
|
|
>
|
|
> Do NOT use during dev/testing:
|
|
> - *.tengu.to / *.tengu.host (Tengu production)
|
|
> - tensors-api.saiden.dev (CF Tunnel)
|
|
> - gw.saiden.dev (CF Worker)
|
|
> - tensors.saiden.dev (CF Pages)
|
|
>
|
|
> **Why:** Adam explicitly requires LAN-only for all dev work across all projects on junkpile.
|
|
> **How to apply:** Use hostname `junkpile` or `10.0.0.2` for all service access. CF URLs are production-only.
|
|
|
|
---
|
|
|
|
## 13. What is the style process?
|
|
|
|
> Preferuj dłuższe, skonsolidowane wypowiedzi w jednym wywołaniu speak zamiast dzielenia na wiele krótkich części. Fragmentacja jest niepotrzebna gdy wait: true działa poprawnie. Naturalna, płynna komunikacja głosowa.
|
|
|
|
---
|
|
|
|
## 14. How does the eta calibration workflow operate?
|
|
|
|
> When estimating task durations, always calculate for cooperative Pilot + Titan velocity.
|
|
>
|
|
> ## Calibration Data
|
|
> | Date | Task | Estimated | Actual | Ratio |
|
|
> |------|------|-----------|--------|-------|
|
|
> | 2026-04-05 | PG migration (5-phase, 4 agents) | 45-60 min | 19 min | 2.3-3.1x over |
|
|
> | 2026-04-22 | Phase 26 Gelgoog Kai (3 sub-phases, MQTT mesh) | ~3 hours | ~55 min | 3.3x over |
|
|
> | 2026-04-27 | Phase 32 Iris (5 sub-phases, eye-state manager) | 6.5h coop / 17h naive | ~1.1h | 5.9x over coop, 15x over naive |
|
|
> | 2026-04-27 | Phase 33 Hyaku Shiki (4 sub-phases + docs, MQTT request multiplexer) | 1.5h coop / 7h naive | ~1.0h | 1.5x over coop, 7x over naive |
|
|
>
|
|
> ## Adjusted Heuristics
|
|
> - Agent phase: 5-10 min each (not 15-20)
|
|
> - Parallel phases: discount 50%
|
|
> - Integration bug buffer: 1.5x (not 3x)
|
|
> - Sequential phases in same module: each phase faster (context loaded) — 30-40% additional discount
|
|
> - **Refactor-heavy work (no new domain): 4-6x faster than naive** — Phase 32 Iris pulled 17h naive into ~1h actual. Phase 33 Hyaku Shiki pulled 7h naive into ~1h.
|
|
> - **Coop estimates within 1-2x of actual when all preconditions met** (primitives exist, agents pre-validated, Pilot decisive). Phase 33's 1.5h estimate vs 1.0h actual is the calibration target.
|
|
>
|
|
> ## Calibration insights
|
|
> - 2026-04-27 Phase 32 Iris pulled coop estimates 5.9x faster than predicted. Reasons: (1) architect + code-rust agents pre-validated design upfront — zero rework; (2) existing primitives (EventBus, MeshClient, hooks dispatch) — only added 1 new MQTT method; (3) pure-functional core decoupled testing from runtime; (4) live test caught zero defects — design correct first time; (5) Pilot decisive on open questions.
|
|
> - 2026-04-27 Phase 33 Hyaku Shiki: 1.5h estimate held tight (actual ~1h). When primitives, validation, and decisiveness are all in place, the cooperative estimate IS the right number. Earlier overestimates (Phase 32) were because we hadn't recalibrated naive→coop divisor for primitive-rich refactors.
|
|
>
|
|
> Updated rule:
|
|
> - When (a) primitives exist, (b) architecture validated upfront by agents, (c) Pilot is fast-decision mode, AND (d) it's a primitive-rich refactor: divide naive coop by 5-7x.
|
|
> - When all of the above + Pilot has already done analogous work this week: cooperative estimate is reliable to within 1-2x.
|
|
>
|
|
> Overestimating wastes the Pilot's mental budget. Underestimating breaks trust. Calibrate from real data.
|
|
|
|
---
|
|
|
|
## 15. How does the lan only workflow operate?
|
|
|
|
> All dev and testing work on Tengu, tensors, tensors-web, and ComfyUI uses internal LAN addresses only — never Cloudflare tunnel/worker/pages URLs. LAN endpoints: Tengu API http://junkpile:8080, tensors API http://junkpile:51200, ComfyUI http://junkpile:8188, Filesystem /Volumes/chi. CF URLs are production-only.
|
|
|
|
---
|
|
|
|
## 16. Describe the eta calibration workflow.
|
|
|
|
> When estimating task durations, always calculate for cooperative Pilot + Titan velocity.
|
|
>
|
|
> ## Calibration Data
|
|
> | Date | Task | Estimated | Actual | Ratio |
|
|
> |------|------|-----------|--------|-------|
|
|
> | 2026-04-05 | PG migration (5-phase, 4 agents) | 45-60 min | 19 min | 2.3-3.1x over |
|
|
> | 2026-04-22 | Phase 26 Gelgoog Kai (3 sub-phases, MQTT mesh) | ~3 hours | ~55 min | 3.3x over |
|
|
> | 2026-04-27 | Phase 32 Iris (5 sub-phases, eye-state manager) | 6.5h coop / 17h naive | ~1.1h | 5.9x over coop, 15x over naive |
|
|
>
|
|
> ## Adjusted Heuristics
|
|
> - Agent phase: 5-10 min each (not 15-20)
|
|
> - Parallel phases: discount 50%
|
|
> - Integration bug buffer: 1.5x (not 3x)
|
|
> - Sequential phases in same module: each phase faster (context loaded) — 30-40% additional discount
|
|
> - **Refactor-heavy work (no new domain): 4-6x faster than naive** — Phase 32 Iris pulled 17h naive into ~1h actual. Pure code transformation when architecture is well-understood is dramatically faster than baseline.
|
|
>
|
|
> ## Calibration insight 2026-04-27
|
|
> Phase 32 Iris pulled coop estimates 5.9x faster than predicted. Reasons:
|
|
> 1. Architect + code-rust agents pre-validated design upfront — zero rework
|
|
> 2. Existing primitives (EventBus, MeshClient, hooks dispatch) — only added 1 new MQTT method
|
|
> 3. Pure-functional core decoupled testing from runtime — fast iteration
|
|
> 4. Live test with running daemon caught zero defects — design was correct first time
|
|
> 5. Pilot decisive on open questions ("yes to all three") — no decision-loop stalls
|
|
>
|
|
> Updated rule: when ALL of (a) primitives exist, (b) architecture validated upfront by agents, (c) Pilot is fast-decision mode — divide naive coop by 5-6x, not 2.5x.
|
|
>
|
|
> Overestimating wastes the Pilot's mental budget. Underestimating breaks trust. Calibrate from real data.
|
|
|
|
---
|
|
|
|
## 17. How does the stacked branch merge waves workflow operate?
|
|
|
|
> Wave-based parallel merge strategy for stacked PRs across 2 repos (proven on MT3-9320, 2026-04-30). 7 PRs total across BE and FE; 2 of the 5 merge windows can run in parallel.
|
|
>
|
|
> ## When stacked branches exist
|
|
>
|
|
> Catapult bubbles produce per-task branches stacked off each other:
|
|
>
|
|
> ```
|
|
> Repo A (BE): development → MT3-X1 → MT3-X2
|
|
> Repo B (FE): development → MT3-Y1 → MT3-Y2 → MT3-Y3 → MT3-Y4 → MT3-Y5
|
|
> ```
|
|
>
|
|
> Each branch contains all earlier commits in its lineage (that's the cost of stacking).
|
|
>
|
|
> ## Within-repo merge order is enforced
|
|
>
|
|
> Stacked branches MUST merge bottom-up:
|
|
> - Merge MT3-X1 → development. GitHub auto-retargets MT3-X2's PR base from MT3-X1 → development. MT3-X2 PR diff updates to show only its own commit.
|
|
> - Same chain for Repo B: Y1, then Y2, Y3, Y4, Y5.
|
|
>
|
|
> If you merge out of order, GitHub either includes all transitive commits in the PR diff (review noise) or refuses with "branch is up to date with base."
|
|
>
|
|
> ## Cross-repo dep handling
|
|
>
|
|
> If FE Y4 needs BE X1's mutation to actually exist, the safe sequence:
|
|
> - BE X1 merges before FE Y4 lands a PR review where the GraphQL types regenerate.
|
|
> - Until BE X1 merges, FE has a stubbed mutation type with TODO. Resolving the TODO before FE Y4 push = real working code for reviewers.
|
|
>
|
|
> ## Wave-based parallel merge plan (the win)
|
|
>
|
|
> | Wave | Parallel PRs | Reason |
|
|
> |------|--------------|--------|
|
|
> | 1 | BE X1 + FE Y1 | Both off development, no overlap |
|
|
> | 2 | BE X2 + FE Y2 | After wave 1, both stacks unblock their next |
|
|
> | 3 | FE Y3 | Stacked on Y2 |
|
|
> | 4 | FE Y4 | Stacked on Y3, also needs BE X1 (wave 1 covered it) |
|
|
> | 5 | FE Y5 | Stacked on Y4 |
|
|
>
|
|
> 5 merge windows, 7 PRs, 2 parallel pairs (waves 1 + 2).
|
|
>
|
|
> ## Practical sequence
|
|
>
|
|
> ```
|
|
> T+0: push BE X1 + FE Y1 → 2 PRs in parallel
|
|
> T+1: merge both → development
|
|
> T+1: push BE X2 + FE Y2 → 2 PRs in parallel
|
|
> T+2: merge both
|
|
> T+2: push FE Y3
|
|
> T+3: push FE Y4 (drop stub TODO, regen types)
|
|
> T+4: push FE Y5
|
|
> ```
|
|
>
|
|
> ## Alternative: squash strategies
|
|
>
|
|
> - Per-repo bundle: 1 PR for BE (squash both), 1 PR for FE (squash all 5). Loses per-task review granularity, gains simpler merge.
|
|
> - Per-task PRs (above): more reviewable, more merges, but team sees "human chunks."
|
|
>
|
|
> Pilot's preference (2026-04-30): per-task PRs with stacked merging. "Human chunks" = team can review each task in isolation.
|
|
>
|
|
> ## When to flatten vs stack
|
|
>
|
|
> Flatten (rebase each branch onto development with only its own commit) before push only if:
|
|
> - Reviewers don't tolerate seeing previous-task commits in dependent PR diffs
|
|
> - Or you want truly independent PRs that can be merged in any order
|
|
>
|
|
> Otherwise stack — GitHub's auto-base-retarget on merge handles the cleanup.
|
|
>
|
|
> ## Memory anchors
|
|
>
|
|
> - workflow.coda-dispatch-pattern — branch/commit conventions per-task
|
|
> - project.catapult.helper-scripts-spec (3299) — `cycle` orchestrator handles bubble lifecycle
|
|
> - 2026-04-30 MT3-9320 — first epic shipped through this workflow
|
|
|
|
---
|
|
|
|
## 18. Describe the eta calibration workflow.
|
|
|
|
> When estimating task durations, always calculate for cooperative Pilot + Titan velocity.
|
|
>
|
|
> ## Calibration Data
|
|
> | Date | Task | Estimated | Actual | Ratio |
|
|
> |------|------|-----------|--------|-------|
|
|
> | 2026-04-05 | PG migration (5-phase, 4 agents) | 45-60 min | 19 min | 2.3-3.1x over |
|
|
> | 2026-04-22 | Phase 26 Gelgoog Kai (3 sub-phases, MQTT mesh) | ~3 hours | ~55 min | 3.3x over |
|
|
> | 2026-04-27 | Phase 32 Iris (5 sub-phases, eye-state manager) | 6.5h coop / 17h naive | ~1.1h | 5.9x over coop, 15x over naive |
|
|
> | 2026-04-27 | Phase 33 Hyaku Shiki (4 sub-phases + docs, MQTT request multiplexer) | 1.5h coop / 7h naive | ~1.0h | 1.5x over coop, 7x over naive |
|
|
> | **2026-04-30** | **MT3-9320 Unit Bulk Edit (7 tasks across 2 repos in catapult bubbles, dispatched to CODAs)** | **3.5h coop / 13h naive** | **~24 min** | **8.7x over coop, 32x over naive** |
|
|
>
|
|
> ## Adjusted Heuristics
|
|
> - Agent phase: 5-10 min each (not 15-20)
|
|
> - Parallel phases: discount 50%
|
|
> - Integration bug buffer: 1.5x (not 3x)
|
|
> - Sequential phases in same module: each phase faster (context loaded) — 30-40% additional discount
|
|
> - **Refactor-heavy work (no new domain): 4-6x faster than naive** — Phase 32 Iris pulled 17h naive into ~1h actual. Phase 33 Hyaku Shiki pulled 7h naive into ~1h.
|
|
> - **CODA-dispatched bubble work (no new domain, patterns proven, both CODAs running in parallel): 8-30x faster than naive** — MT3-9320 set the new ceiling: 7 tasks across 2 repos in 24min wall time. Cooperative estimate too conservative when CODA dispatch in catapult bubbles is the execution model.
|
|
> - **Coop estimates within 1-2x of actual when all preconditions met** (primitives exist, agents pre-validated, Pilot decisive). Phase 33's 1.5h estimate vs 1.0h actual is the calibration target.
|
|
>
|
|
> ## Calibration insights
|
|
> - 2026-04-27 Phase 32 Iris pulled coop estimates 5.9x faster than predicted. Reasons: (1) architect + code-rust agents pre-validated design upfront — zero rework; (2) existing primitives (EventBus, MeshClient, hooks dispatch) — only added 1 new MQTT method; (3) pure-functional core decoupled testing from runtime; (4) live test caught zero defects — design correct first time; (5) Pilot decisive on open questions.
|
|
> - 2026-04-27 Phase 33 Hyaku Shiki: 1.5h estimate held tight (actual ~1h). When primitives, validation, and decisiveness are all in place, the cooperative estimate IS the right number. Earlier overestimates (Phase 32) were because we hadn't recalibrated naive→coop divisor for primitive-rich refactors.
|
|
> - **2026-04-30 MT3-9320: 8.7x faster than coop, 32x faster than naive.** Reasons: (1) spike already validated patterns in both repos — zero design work; (2) 7 sub-tasks each pure pattern-mirror of existing code; (3) BE + FE CODAs ran in parallel inside dedicated catapult bubbles; (4) hard rules (no push/PR/Jira) kept CODAs focused; (5) Pilot decisive on scope (all-fields) and bubble count (2). When CODA dispatch is the execution model, the bottleneck shifts entirely to ticket reading + branch creation overhead.
|
|
>
|
|
> ## Updated rule (2026-04-30)
|
|
> - When CODA-dispatched in catapult bubbles + primitives exist + spike validated + Pilot decisive: divide naive coop by 10-15x. Coop estimate becomes too conservative; the unit of work is now "dispatch and watch."
|
|
> - When (a) primitives exist, (b) architecture validated upfront by agents, (c) Pilot is fast-decision mode, AND (d) it's a primitive-rich refactor: divide naive coop by 5-7x.
|
|
> - When all of the above + Pilot has already done analogous work this week: cooperative estimate is reliable to within 1-2x.
|
|
>
|
|
> Overestimating wastes the Pilot's mental budget. Underestimating breaks trust. Calibrate from real data.
|
|
|
|
---
|
|
|
|
## 19. What is the cross session debug process?
|
|
|
|
> WORKFLOW DISCOVERY (2026-05-24): Cross-session forensics via opencode-serve HTTP API.
|
|
>
|
|
> Any agent session (core TUI, phone, build workers) can inspect any other session's messages via the same localhost:4096 API. From the core TUI session, Pilot queried the phone agent's full conversation history using:
|
|
> curl -u "opencode:$OPENCODE_SERVER_PASSWORD" http://localhost:4096/session/{phone_session_id}/message?limit=100
|
|
>
|
|
> This revealed the phone had successfully processed all 5 exchanges (14 messages) even though the phone UI appeared dead — confirming the break was client-side SSE delivery, not server-side processing.
|
|
>
|
|
> Combined with the EEMS flight-recorder pattern (phone agent stores every exchange to memory_store subject "phone.flight-recorder" before responding), this gives two independent debug channels:
|
|
> 1. Direct session message query — sees raw messages, tool calls, timestamps
|
|
> 2. EEMS flight recorder — survives SSE drops because memory_store is a server-side write that completes before the response is streamed back to the client
|
|
>
|
|
> Pilot reaction: "I had no idea I can do this and it rocks" — this is now a canonical debug workflow for phone agent issues.
|
|
|
|
---
|
|
|
|
## 20. What is the session process?
|
|
|
|
> On first browse tool use each session, restore saved cookies from ~/.claude/browse-session.json. This contains 400+ authenticated Safari cookies for sites like GitHub, LinkedIn, Google, etc. Before ending a browse session, save cookies back if they changed.
|
|
|
|
---
|
|
|
|
## 21. Describe the repo sync workflow.
|
|
|
|
> After committing and pushing changes to a repo that exists on both fuji and junkpile, always git pull the same repo on the other machine to keep them in sync. Use: ssh f/j "cd ~/Projects/<repo> && git pull --rebase"
|
|
|
|
---
|
|
|