signal-ingestlisted

# signal-ingest — observed behaviour as evidence, never as an answer Follow the shared contract in `../README.md`. `need-understanding` raises the ambiguities a requirement leaves open, and `openapi-ingest` raises the ones a specification leaves open: *is `limit` bounded?*, *which status does a duplicate registration return?*. Both hand those questions to a human, who then arbitrates them blind — while the running system answers them a thousand times a day and nobody writes it down. This skill closes that gap **without ever deciding anything**. It attaches observed evidence to an existing question so the human who arbitrates it stops arbitrating blind. ## The line this skill does not cross **It reads a file the user exports and hands over. It never connects to anything.** No endpoint, no credential, no APM token, no log stream, no polling. The project's scope decision keeps production *monitoring* out; ingesting an artefact someone chose to export is the same shape as `traffic-replay` reading a HAR, and stays inside it. If asked to fetch the data itself, refuse and say what to export instead. ## Accepted inputs | Input | What is extracted | |---|---| | access-log extract | path, method, status, count | | status-code breakdown (CSV/JSON) | path × status frequency | | error-rate or APM export | error class, endpoint, frequency, first/last seen | | HAR capture | request/response pairs — hand to `traffic-replay` for test generation, here only for evidence | | a table past