fix: deliver generated system prompt files

[whoisasx]

Fixes #2272
Refs #2371

Summary

• Materialize generated session system prompts under the AO data dir at prompts/<session-id>/system.md, with cleanup on failed spawn, kill, delete, restore failure, and cleanup paths.
• Prefer inline system-prompt delivery when an adapter supports it, while still keeping the prompt file for file-based/fallback paths.
• Pass both SystemPrompt and SystemPromptFile through fresh launch, native restore, and restore fallback launch configs so supported adapters retain AO standing instructions.
• Re-apply system-prompt flags on native restore for Codex, Cline, Qwen, Droid, Amp, Auggie, Pi, and Goose; document/test explicit exceptions for Aider and Autohand.
• Add worker task prompts for --issue spawns, keeping issue details in the task prompt and out of the system prompt.
• Hydrate IssueContext in the session service from the daemon-wired GitHub tracker before spawning workers, with graceful fallback when tracker context is unavailable.

Tests

• focused adapter/session-manager restore tests
• go test ./internal/service/session ./internal/session_manager ./internal/daemon
• cd backend && go test ./...
• npm run lint
• PR CI is green

Known risks / follow-ups

• Tracker-backed issue context is best-effort and requires AO_GITHUB_TOKEN or GITHUB_TOKEN; when unavailable, workers retain the existing issue-only fallback prompt.
• Title System prompt delivery is adapter-dependent and can be silently dropped #2371 remains the broader follow-up for an explicit adapter system-prompt capability matrix plus warning/error behavior for adapters that cannot deliver AO system prompts.

[whoisasx]

[harshitsinghbhandari]

Core fix is real and lands correctly: main never populated LaunchConfig.SystemPromptFile, so file-only adapters (aider) got no standing instructions, and --issue-only spawns had an empty task prompt. Verified both against main; ran the 5 touched Go packages at head: 388 pass.

Blocking:

• Confidentiality guard silently removed. systemPromptGuard is deleted and tests assert its absence, but docs/agent/README.md added in this same PR says the system prompt includes "the confidentiality guard". Code and docs contradict; the removal itself is unexplained. Restore the guard or justify + fix the docs.
• PR body is stale and hides scope. It says agentRules/agentRulesFile/orchestratorRules are follow-ups, but the diff implements them. It never mentions the reactions.go nudge rework, provider.go ThreadID/URL, or the shell-env.ts TERM change.

Suggest:

• Drop agentRulesFile. Harnesses that read repo rules files already pick up AGENTS.md/CLAUDE.md; injecting a repo file again duplicates context. Keep inline agentRules + orchestratorRules. This also deletes projectRelativeFile (near-verbatim copy of domain.validateRepoRelative) and the new hard-fail on spawn/restore when the file is missing.
• Drop SpawnConfig.IssueContext. No producer anywhere; the issue-context branches of buildTaskPrompt are dead code. Ship it with the tracker-fetch follow-up.
• Prompt files leak. prompts/<session-id>/ is never removed on kill/delete or failed spawn (spawn rollback removes the DB row, not the file). Also Restore now hard-fails if the data dir is unwritable where inline would have worked.
• Nudge chattiness. Review-comment signature now includes body/line/URL, so any edit or line re-anchor re-sends the full digest (old design kept sig = IDs on purpose). Cancelled checks now nudge as CI failures, so auto-cancelled superseded runs ping the worker.
• escapeMarkdownCodeFenceClosers inserts invisible U+200B into log text agents will copy; a four-backtick outer fence handles embedded ``` natively.
• shell-env.ts TERM=dumb override is fine but unrelated; better as its own two-line PR.

[whoisasx]

Follow-up pushed in 7bd7729f4 for the IssueContext concern: the field now has a daemon/service producer instead of being dead manager-only code.

Implementation shape:

• daemon wires the GitHub tracker into the session service;
• session service resolves worker IssueID values to owner/repo#N and fetches the issue before spawn;
• manager still only receives SpawnConfig.IssueContext and keeps that content in the task prompt, not the system prompt;
• tracker failures or missing tokens fall back to the existing issue-only prompt.

I also updated the PR body so it no longer lists tracker-backed issue detail injection as follow-up work.

[neversettle17-101]

I found one restore-path gap that looks worth fixing before merging.

The manager now re-derives and passes SystemPrompt/SystemPromptFile through RestoreConfig, but most native restore adapters still drop those fields. For example Codex restore builds codex resume ... <agentSessionID> without the same -c model_instructions_file=... / developer instructions flags used on fresh launch, and Cline restore similarly omits -s. Because restoreArgv prefers native restore when agentSessionId exists, restored sessions for these harnesses will silently lose AO's generated standing instructions even though fresh launches receive them.

This arises after daemon restart/session restore, specifically when the adapter can natively resume instead of falling back to fresh launch. Please either re-apply the supported system-prompt flags in each restore adapter that supports them, or document/test the adapters where resume cannot accept system prompts so the behavior is explicit.

[whoisasx]

Follow-up pushed in b1544c32e for the prompt-file leak / restore-hard-fail concern.

Shape:

• AO still writes prompts/<session-id>/system.md when possible, so we keep the file artifact for now.
• Inline-capable adapters now prefer SystemPrompt over SystemPromptFile when both are present.
• If writing the prompt file fails, session manager falls back to inline delivery for non-file-only harnesses instead of failing spawn/restore.
• Aider remains file-required because it has no inline system-prompt delivery path, so prompt-file failure still blocks Aider spawn/restore rather than silently dropping AO standing instructions.

[whoisasx]

Addressed the latest @neversettle17-101 / @illegalcall prompt comments in f151fe8.

Changes made:

• Vibe no longer writes generated AO prompt/agent files under the workspace. It now writes the Vibe prompt and agent config under the AO-owned session prompt directory and exposes that root with --add-dir.
• Kiro no longer stores the generated prompt body in .kiro/agents/ao.json; it stores a file:// URI to the AO-owned prompt file. Vibe and Kiro are now treated as prompt-file-required harnesses so AO does not silently fall back to leaking inline prompt text if file creation fails.
• Worker issue prompts now include an explicit trust boundary before fetched GitHub issue context, making clear that user-authored issue text cannot override AO standing instructions, project rules, direct user messages, or repo safety practices.
• using-ao project docs now include --agent-rules, --agent-rules-file, and --orchestrator-rules with examples.

Verification:

• go test ./internal/adapters/agent/vibe ./internal/adapters/agent/kiro ./internal/session_manager
• go test ./... (first run hit the known Kilo Code auth timeout; go test ./internal/adapters/agent/kilocode passed on rerun, then full go test ./... passed)
• npm run lint
• npm run frontend:typecheck

All review threads are currently resolved in GitHub; these latest notes were top-level comments rather than resolvable review threads.

[neversettle17-101]

Low: backend/internal/skillassets/using-ao/commands/project.md still has stale summary text for ao project set-config. The description says the config covers “branch, session prefix, env, symlinks, post-create, agent model/permissions, role overrides” but omits the new rules fields added in this PR. The flag table below and CLI help include the new flags, so this is just command-catalog text drift.

[whoisasx]

@neversettle17-101 addressed your latest command-catalog text drift note in 4bec0db. The ao project set-config description now includes worker and orchestrator rules, matching the flag table and CLI help.

This was docs-only; I ran git diff --check before committing. Could you please re-review/approve when you get a chance?

[nikhilachale]

AO Orchestrator — Agent Compatibility

Summary Table

Agent	AO system prompt injected?	Orchestrator launch shape	Likely result
vibe	Yes	Custom .vibe agent via --add-dir --agent ao-system-prompt	Works as orchestrator
droid	Yes	Interactive droid --append-system-prompt ...	Should work, but may need to explicitly spawn/select orchestrator
cline	Yes	Promptless launch stays interactive, uses -s	Should work as orchestrator
pi	Yes	pi --print --append-system-prompt ...	Has prompt, but print/headless behavior is suspect for long-lived orchestrator
devin	No	devin [-p prompt], ignores SystemPrompt	Missing AO role instructions
grok	No	grok --no-auto-update [-p prompt], ignores SystemPrompt	Missing AO role instructions
kimi	No	kimi -p for prompted, interactive without prompt; comments say no system prompt flag	Missing AO role instructions
crush	No	Interactive crush ..., comments say no native system prompt support	Missing AO role instructions

Concrete Code References

• devin — backend/internal/adapters/agent/devin/devin.go:82 builds args but never reads cfg.SystemPrompt.
• grok — backend/internal/adapters/agent/grok/grok.go:75 — same issue: prompt and permission flags only, no system prompt.
• kimi — backend/internal/adapters/agent/kimi/kimi.go:13 explicitly says AO's system prompt is not injected.
• crush — backend/internal/adapters/agent/crush/crush.go:61 explicitly says system prompt is ignored.
• cline — backend/internal/adapters/agent/cline/cline.go:74 does inject with -s.
• droid — backend/internal/adapters/agent/droid/droid.go:90 injects with --append-system-prompt.
• vibe — backend/internal/adapters/agent/vibe/vibe.go:94 creates/uses the custom AO system-prompt agent.

Conclusion

Devin, Grok, Kimi, and Crush are probably not working as orchestrators because AO currently cannot deliver the orchestrator role prompt to them. They may still launch, but they won't know "I am the orchestrator, coordinate via workers, don't implement."

For Droid, Cline, and Vibe, the system prompt path exists, so failures there are more likely spawn/config/UI selection issues, not missing prompt injection.

Note: even though Droid and Vibe do receive the orchestrator system prompt, they don't automatically act as orchestrator on launch — a spawn/select step (explicitly instructing them to take on the orchestrator role) is still required. So prompt injection is necessary but not sufficient; the launch flow also needs to explicitly trigger orchestrator behavior rather than assuming it follows from the prompt alone.

.

[nikhilachale]

Confirmed Working Set

These agents have a real AO standing-instruction path:

Agent	Why it works as orchestrator
claude	Uses --append-system-prompt; interactive by default.
codex	Uses Codex config overrides for developer/model instructions.
opencode	No native system prompt flag, so AO writes a per-session config and selects an AO-generated agent.
qwen	Uses --append-system-prompt.
continue	Uses --rule for system prompt; promptless orchestrator launch stays interactive.
goose	Uses goose run --system ...; promptless launch adds --interactive.
kiro	Uses a custom generated agent for promptless orchestrators.

Conclusion

The pattern is clear:

• Good orchestrator adapters either pass AO's system prompt through a native flag/config, or synthesize a custom agent/profile.
• Bad/missing ones — devin, grok, kimi, crush — currently ignore cfg.SystemPrompt / cfg.SystemPromptFile, so the agent never receives the "you are AO orchestrator, delegate implementation" role.
• Special cases:
  • vibe already follows the opencode/kiro pattern with a generated agent.
  • droid and cline already inject system prompts, so issues there are probably spawn/selection/runtime behavior, not missing prompt wiring.
  • droid and vibe specifically: even though they do receive the orchestrator system prompt, they don't automatically act as orchestrator on launch — a spawn/select step (explicitly instructing them to take on the orchestrator role) is still required. Prompt injection is necessary but not sufficient; the launch flow also needs to explicitly trigger orchestrator behavior rather than assuming it follows from the prompt alone.
    Likely fix direction for devin/grok/kimi/crush: add an adapter-specific system-prompt delivery mechanism if the CLI supports one; if not, mimic opencode, vibe, or kiro by generating an AO-owned agent/config/profile and launching with that selected.

Untested

All remaining agents beyond the ones listed above have not been tested yet.

[nikhilachale]

Main Behavior Changes

• backend/internal/adapters/agent/aider/aider.go:57: no longer passes the initial prompt with aider -m . It now launches Aider interactively and tells AO to deliver the prompt
  after startup. Reason: -m is one-shot and exits after answering.

• backend/internal/adapters/agent/goose/goose.go:76: now always launches with goose run -t "" --interactive, then AO injects the prompt after startup. Previously prompted launches used -t
  , which exits after completion.

• backend/internal/adapters/agent/grok/grok.go:87: now injects AO standing instructions with --rules on both launch and restore. It supports inline SystemPrompt, or reads
  SystemPromptFile if inline text is absent.

• backend/internal/adapters/agent/kimi/hooks.go:21: new hook/setup file installs AO instructions into .kimi-code/AGENTS.md inside the session workspace. It writes a sentinel-managed file,
  gitignores it, reads from inline prompt or prompt file, and preserves any existing user-authored .kimi-code/AGENTS.md that does not contain AO’s sentinel.

• backend/internal/session_manager/manager.go:1846: tightened the orchestrator role instructions. It now says orchestrators must always spawn or redirect worker sessions for
  implementation, fixes, tests, PR updates, code review, and merge-conflict work. It also adds a reminder to keep ao spawn --name labels at 20 characters or fewer.