service-boundary-analysislisted

# Service Boundary Analysis ## Contract Statically inspect one backend service, module, worker, or API. Identify inputs and externally visible outputs. No execution, edits, security review, schema design, or certainty for dynamic wiring. Require exact target, scope, exclusions, report path. Multi-service workspaces get one report per service. ## Taxonomy Inputs: HTTP/API, RPC, messages/streams, WebSocket/SSE, scheduled jobs, CLI/batch/workers, file/object triggers, config loading. Outputs: database writes, external calls, event publishing, cache changes, file/object writes, search/vector writes, notifications, job scheduling, boundary-relevant telemetry. Ignore local debug logs. ## Evidence Use routes, annotations, registrations, imports, handlers, clients, repositories, publishers, schedulers, config, healthy graph edges. Trace cross-file wiring before relying on names. - `high`: direct mechanism and peer/destination evidence. - `medium`: corroborated registration, convention, or cross-file wiring. - `low`: plausible, incomplete, or dynamic. Each row includes `file:line`, symbol when available, discovery method. Put unresolved reflection, generation, missing config, or indirection under `Uncertain`; never inflate confidence. ## Flow 1. Detect language/framework from manifests, target files. 2. Find input registrations, handlers. 3. Find output clients, side effects. 4. Trace each candidate to peer/destination. 5. Group repeated equivalent boundaries. 6. Write one