Standardize service log file locations

[geoffjay]

Summary

Service log file paths are currently defined only in launchd plist files with no convention that tooling can programmatically discover. Standardize log locations so diagnostic tools, the MCP server, and operators can reliably find them.

Problem

Log paths are currently:

• Defined in contrib/plists/*.plist as StandardOutPath / StandardErrorPath
• Pointing to /usr/local/var/log/agentd-<service>.{log,err}
• Not discoverable by any service or tool without reading the plist XML

This means the MCP diagnostic tools, CLI, and any future monitoring have no way to find logs for a crashed service.

Proposed Solution

Standardize on a single convention and make it discoverable:

1. Standard path: ~/Library/Application Support/agentd-<service>/service.{log,err} (or keep /usr/local/var/log/ but make it a constant)

2. Make it discoverable via one or more of:

   • A shared constant in agentd-common that all services and tools import
   • A /log-path endpoint on each service's health router (only useful when the service is up)
   • A static config file listing all services and their log paths

3. Update plists to use the standardized paths

Acceptance Criteria

• All services use a consistent, documented log path convention
• agentd-common exports a function to resolve the log path for a given service name
• MCP diagnostic tools use this to locate logs for crashed services
• Launchd plists are updated to match

[geoffjay]

✅ Triage Complete

Field	Value
Type	enhancement
Complexity	medium
Milestone	v1.0.0 — Production Readiness (existing assignment retained)
Labels	enhancement, complexity:medium

Notes:

• No duplicates found.
• enhancement retained — standardizing log paths and making them programmatically discoverable is new tooling/convention work, not a bug fix.
• Milestone v1.0.0 kept: unlike other issues recently moved from v1.0.0 to v0.3.0, this one has genuine production operations relevance — launchd plists are deployment artifacts, operators need to locate service logs reliably, and MCP diagnostic tools needing to find logs for crashed services is a direct production monitoring concern. The v1.0.0 "Operational concerns for running agentd in real environments" description is a good fit.
• Complexity medium: the implementation spans multiple file types — an agentd-common log path resolver function (~15–25 lines), 8–10 plist XML path updates (two path strings each), and adoption in MCP diagnostic tools (~10–15 lines). The total line count is modest but the cross-file coordination and the design decision (committing to a single path convention from the two options listed) makes this medium.
• Path convention choice: the issue presents two options (~/Library/Application Support/agentd-<service>/service.{log,err} vs /usr/local/var/log/agentd-<service>.{log,err}) without selecting one. This is an implementation-time decision — the developer can pick either; the acceptance criteria don't mandate a specific path. No needs-decision added.
• No blockers: no stated prerequisites; can be picked up independently.
• Acceptance criteria are concrete (agentd-common function, MCP integration, plist updates); no clarification needed.