# Connected coding workflows — evidence worksheet

By Heksync, the maker of LoopCode. Published 27 October 2026.
These are adaptable checklists, not certification or a model benchmark.
Use test accounts, permitted code, and disposable data. Hosted inference may
process relevant prompts, code, and tool results.

## 1. MCP: one issue to a reviewed patch

- Repository and commit:
- Test issue and source URL:
- Expected behavior and acceptance criteria:
- Connected servers and the identity signed in to each:
- Tools actually enabled (use each server's returned tool names):
- Service-side access scopes and LoopCode permission rules:
- Sanitized event or other evidence (do not copy credentials):
- Reproduction command and result before editing:
- Relevant implementation and callers:
- Final changed files:
- Regression and integration commands after the final edit:
- Actual results and unverified boundaries:
- Draft handoff reviewed by:

Keep issue updates, messages, deployment, and production writes separate from
local implementation. A server's read-only annotation is its own declaration;
it is not a sandbox or proof of the server's behavior.

Article: https://loopcode.heksync.in/blog/mcp-coding-agent-issue-to-patch

## 2. LSP: rename a symbol without changing external contracts

- Repository, commit, and target symbol:
- Language server, version if available, and readiness:
- Project root and files visible to the server:
- Definition and reference results:
- Proposed semantic edits:
- JSON keys, event/metric names, and public exports to preserve:
- Remaining matches for the original spelling, classified by purpose:
- Generated clients, dynamic consumers, and other repositories to inspect:
- Typecheck and behavioral test commands:
- Final results, compatibility decisions, and unverified consumers:

A semantic rename can be more precise than global text replacement. Neither a
rename result nor a passing compile proves all external consumers are safe.

Article: https://loopcode.heksync.in/blog/lsp-ai-agent-refactoring
Fixture: https://loopcode.heksync.in/resources/loopcode-refactor-example.ts

## 3. Browser: verify the behavior behind a success message

- Test URL and dedicated account (do not record its password):
- Repository commit and environment:
- Feature's intended save and error contract:
- Unique disposable test value:
- Browser interaction and observed result:
- Handler/API/integration evidence for the write:
- Independent fresh read and any cache boundaries:
- Reload result:
- Controlled rejection setup and recovery result:
- Keyboard and narrow-viewport observations:
- Screenshots, final check commands, and results:
- Mocks, unavailable observations, and remaining verification:
- Test-data cleanup if supported:

A screenshot proves only what was visible. A reload might restore client-side
state. Use independent data-layer checks for a server-persistence claim.

Article: https://loopcode.heksync.in/blog/browser-agent-verify-web-app