| Filename | Latest commit message | Latest commit date |
|---|---|---|
91e1392c1f
Copilot review round 4 — four comments, all the same finding against the four files carrying the claim, and it was more than a wording problem. The comment said a holder whose lock was replaced is told. Checked against proper-lockfile@4.1.2, that is false in the case that actually happens: - `updateLock` compares mtime only on its refresh tick — `stale / 2`, so 5s here — while an ordinary mutation is a read, an scrypt derivation and an atomic write, comfortably under a second. The tick never runs, so nothing fires. - `release` → `unlock` → `removeLock` is an unconditional `rmdir` with **no ownership check**. So the compromised holder goes on to delete the *winner's* lock on the way out, ending the winner's exclusion too: one compromised writer silently becomes two unprotected ones. The second half is a correctness bug, not a documentation defect, and it is fixable here even though the takeover race itself is not. `withSecretFileLock` now records the lock directory's inode and birth time at acquire and re-checks them before releasing. On a mismatch it **declines to release** — leaving the new holder's lock alone costs nothing, ours is already gone — and warns. Inode and birth time rather than mtime, deliberately: both survive the library's own `utimes` refresh, so a lock held past one tick is not accused of being compromised, and both change on a delete-and-recreate, which is exactly the event to detect. Where a filesystem reports neither, the two reads agree and the check concludes "ours", degrading to the library's unaided behaviour rather than to a false alarm. An unreadable baseline at acquire likewise answers "ours" — with nothing to compare against, accusing a healthy lock would be worse than releasing it. Detection is therefore **best-effort**, and file-lock.ts, README.md, specification/v2_servers_file.md and AGENTS.md now all say so rather than promising the loser is told. AGENTS.md carries the negative instruction too, since this is the second round spent on the same overclaim. Tests: "does not delete the winner's lock after being taken over" replaces the lock inside the body and asserts the replacement survives with the *same* inode and birth time — it was left alone, not deleted and recreated. It waits for nothing, being the fast case the library's tick misses. Verified by mutation: forcing `stillOurs` to always answer true fails it. A second test covers a release that fails while the lock genuinely *is* ours (a stray file makes `rmdir` fail ENOTEMPTY), so the ownership check cannot swallow a real release failure. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JTHVxSu8AUgHRLvo1ntZ8H Signed-off-by: cliffhall <cliff@futurescale.com> |
||
| .. | ||
| diagrams | ||
| screenshots | ||
| README.md | ||
| v1_problems.md | ||
| v2_auth.md | ||
| v2_auth_ema.md | ||
| v2_auth_hardening.md | ||
| v2_auth_mid_session.md | ||
| v2_auth_sdk_consolidation.md | ||
| v2_auth_smoke_testing.md | ||
| v2_catalog_launch_config.md | ||
| v2_cli_tui_launcher.md | ||
| v2_new_spec_impact.md | ||
| v2_scope.md | ||
| v2_screenshots.md | ||
| v2_server.md | ||
| v2_servers_file.md | ||
| v2_storage.md | ||
| v2_ux.md | ||
| v2_ux_components.md | ||
| v2_ux_features.md | ||
| v2_ux_handlers.md | ||
| v2_ux_interfaces.md | ||
| v2_ux_interfaces_phase_0_4_inventory.md | ||
| v2_ux_interfaces_plan.md | ||
| v2_ux_storybook.md | ||
| v2_web_client.md | ||
Inspector V2 Brief
Brief | V1 Problems | V2 Scope | V2 Tech Stack | V2 UX | V2 Auth | V2 New Spec Impact
Table of Contents
- Motivation and Context
- Track Protocol Conformance
- Improve Maintainability
- Provide Extensibility
- Proper Documentation
Motivation and Context
The existing Inspector is hard to maintain for a number of reasons. We decided to create a more maintainable Inspector from the ground up, that retains the deterministic boundary of operation, but exposes a plugin architecture.
Track Protocol Conformance
- Identify any gaps in V1 inspector
- Track which features are covered
- Implement to parity and fill gaps
- Provide conformance testing in CI
Improve Maintainability
- Clearer separation of concerns
- Smaller, reusable components
Provide Extensibility
- Plugin SDK / API
- Third parties cand develop/maintain their own plugins for features such as
- LLM usage
- Evals
- Multiple server connections
- Apps playground
- Testing of registry configuration
- Interface with registry
Proper Documentation
- One big README won't cut it anymore
- Published documentation in MDX should
- Render in style of spec
- Kept up to date
- Cover all features
- Discuss troubleshooting strategies
- Provide detailed contribution guidance that explains architecture and expected idioms