Claude Code recupera il contratto condiviso tramite i record delle dipendenze MCP

Un ingegnere di Bit Cloud ha testato Claude Code in un ambiente pulito privo di storia di conversazione o codice locale. L'agente ha aperto una sessione vuota e, usando lo strumento MCP, ha letto l'ambito bit-oss.support, scoprendo i quattro componenti dell'app di supporto e le loro dipendenze. Successivamente ha chiamato read_components per l'app, il servizio e l'entità ticket, recuperando le API reference e gli inventari di file prima di importare il codice. L'app e il servizio hanno entrambi dipeso dalla stessa versione dell'entità ticket, la cui documentazione di classe recitava "shared between the support service and the agent-facing app". Dopo aver importato i componenti con bit import, Claude ha implementato il filtraggio lato client nell'app, ottenendo 41 test passanti, inclusi nove test nuovi di filtraggio. I record delle dipendenze hanno permesso all'agente di identificare il contratto condiviso senza bisogno di memoria conversazionale.

Tuttavia, i record si sono esauriti quando è emersa la questione comportamentale. La reference API dell'app elenca le route GET /tickets, POST /tickets, PATCH /tickets/:id e POST /tickets/:id/comments per un servizio fittizio usato nei test, ma non verifica che tali route corrispondano a quelle del servizio reale. La corrispondenza tra le route su entrambi i lati va letta manualmente e testata. Inoltre, i test di integrazione MongoDB vengono saltati se il database temporaneo non parte sul runner CI, quindi un build verde non garantisce che i test siano effettivamente eseguiti. L'ingegnere ha verificato la persistenza manualmente creando un ticket, aggiungendo un commento e riavviando la piattaforma sullo stesso database per confermare che i dati restassero presenti.