[Feature] Runtime log access — Xcode console, browser DevTools, server logs

[davesleal]

Context

Agents can read code but are blind to runtime behavior. Xcode console logs, browser DevTools output, server stderr, crash reports — these are all trapped on a screen that only the operator can see. When debugging, the agent asks "what does the log say?" and waits for a copy-paste. This breaks flow and limits the agent's ability to self-diagnose.

Vision

Give agents direct access to runtime logs so they can proactively debug, correlate errors, and add proper logging where it's missing — without waiting for the operator to relay information.

Platform-specific approaches

Xcode / iOS Simulator

• xcrun simctl + log stream — stream iOS Simulator logs to a file the agent can tail
• os_log structured logging — if the app uses os_log, logs can be queried via log show --predicate with subsystem filters
• Build logs — xcodebuild output piped to a file, agent reads for warnings/errors
• Crash logs — ~/Library/Logs/DiagnosticReports/ contains crash reports the agent can read directly

Web / Next.js / Node

• Server logs — pipe next dev stderr to a file, agent tails it
• Browser console — Playwright MCP can execute page.evaluate(() => console.log) or capture console events
• Network logs — Playwright captures network requests/responses

Python / Server

• logging module — configure a file handler that the agent can read
• journalctl — systemd service logs queryable by unit name
• Docker logs — docker logs <container> for containerized services

How it fits the architecture

New discoverable consultant: Log Analyst

• Bootstrapped when Haiku detects log files, os_log usage, or logging config in the project
• Reads recent log output, correlates with code changes
• Suggests adding logging where coverage is thin
• Flags error patterns the primary agent should investigate

Proactive behavior

• After an agent makes code changes and the app is running, the Log Analyst checks logs for new errors/warnings
• If a crash report appears in DiagnosticReports, the agent picks it up without being asked
• Correlates timestamps: "the crash at 14:32 corresponds to the auth change deployed at 14:30"

Cross-app log access

• Agent working on App A needs to check if its API calls are hitting App B's server correctly
• Log Analyst reads App B's server logs to verify the integration
• This is the "resourcefulness" principle — agents don't stay in their lane, they go find the information

Implementation sketch

1. Add tools/log_reader.py:

   • tail_log(path, lines=100) — read last N lines from a log file
   • stream_simulator_logs(bundle_id) — start xcrun simctl spawn booted log stream filtered by bundle
   • read_crash_reports(app_name) — scan DiagnosticReports
   • query_os_log(subsystem, last_minutes=5) — log show --predicate 'subsystem == "..."'

2. Add log-analyst to discoverable consultant roles in tools/consultants.py

3. Trigger: detected when project has Xcode project, Package.swift, logging config, or docker-compose

4. Feature-gated via consultants: true (same as other consultants)

The mindset

This is about agents that are resourceful — they don't wait to be fed information. They know where logs live, they go read them, they correlate what they find with what they're working on. If a crash happened, they find the crash report. If an API call failed, they check the server logs. If a build warning appeared, they read the build output.

The goal: an agent that debugs like a senior developer who has all the terminals open.

Priority

Medium-high for iOS projects (Xcode logs are the primary feedback loop). Medium for web/server.

Related

• [Feature] Computer Use — visual QA and browser automation #15 — Computer Use (visual access to running apps)
• [Feature] Visual UX/Accessibility consultant — WCAG + design system enforcement #16 — Visual UX consultant (sees the UI, this sees the logs)
• Token Cart spec — discoverable roles, agent bootstrapping