AmiteK

GitHub: https://github.com/LogicStamp/logicstamp-context

It compiles TypeScript codebases into deterministic, structured context.

Happy to answer questions.

I agree - that’s on me for the wording. I’m not claiming repeatability of agent inference or LLM sessions.

By “repeatability” I mean the extraction itself: given the same repo state + config, the derived semantic artifact is identical every time. That gives CI and agents a stable reference point, but it doesn’t make agent behavior deterministic.

The value is in not having to re-infer structure from raw source each run - not in making inference runs repeatable.

I think the disagreement is about where inference belongs, not whether LLMs are capable.

Git diffs + LLM inference work well for understanding changes once. What I’m targeting is reducing the need to re-infer semantic surface changes every run, especially across large refactors or long-running workflows.

Today, LogicStamp derives deterministic semantic contracts and hashes, and watch mode surfaces explicit change events. The direction this enables is treating those derived facts as a semantic baseline (e.g. drift detection / CI assertions) instead of relying on repeated inference from raw diffs.

By “repeatability” I mean the artifacts, not agent behavior: same repo state + config ⇒ same semantic model. I don’t yet have end-to-end agent performance evals versus AGENTS.md + LSP

That’s a reasonable hypothesis, and I agree LLMs are very good at inferring structure from raw TypeScript within a local reasoning window. However, that inference has to be repeated as context shifts or resets.

The claim I’m making is narrower: pre-processed structure isn’t about helping the model understand syntax, it’s about removing the need to re-infer relationships every time. The output isn’t a novel language - it’s a minimal, explicit representation of facts (e.g. dependencies, exports, routes) that would otherwise be reconstructed from source.

Inference works well per session, but it doesn’t give you a persistent artifact you can diff, validate, or assert against in CI. LogicStamp trades some inference convenience for explicitness and repeatability across runs.

I don’t claim one dominates the other universally - they optimize for different failure modes.

I think we’re optimizing for different constraints. If your goal is zero extra round trips and you’re happy with AGENTS.md auto-injection + LSP queries, then I agree LogicStamp won’t be a win on token cost for that setup.

The AGENTS.md comparison isn’t “same thing” - it’s a different layer. AGENTS.md encodes human intent/heuristics. LogicStamp generates semantic ground-truth contracts (exports, APIs, routes) from the AST so they can be diffed and validated mechanically (e.g. CI drift detection).

Git + LSP can diff/query source across commits, but that’s still a query workflow. LogicStamp’s goal is a persistent, versioned semantic artifact. If your workflow already covers that, then it may simply not add value - which is totally fine.

On tool-call overhead: in the MCP flow it’s typically 1–2 calls per task (watch_status once, then read_bundle for the relevant slice). In watch mode we also skip snapshot refresh entirely.

Token-wise, the intent isn’t “dump everything”. it’s selective reads of the smallest relevant bundles. If your workflow already achieves what you want with AGENTS.md + LSP querying, that may indeed be more token-efficient for many sessions.

The trade-off LogicStamp is aiming for is different: verifiable, diffable ground-truth artifacts (CI/drift detection/cross-run guarantees). Tokens aren’t the primary optimization axis.

I think there’s a conflation here between artifact determinism and agent behavior.

LogicStamp’s determinism claim is about the generated context: same repo state + config ⇒ identical bundles. That property holds regardless of how or when an agent chooses to read them.

Tool calls don’t make the artifacts non-deterministic; they only affect when an agent consumes already-deterministic output.

That’s fair, and I agree LSP-style search is excellent for interactive, local exploration. LogicStamp isn’t trying to replace that.

The problem it targets is different: producing stable, explicit structure (public APIs, components, routes) that can be diffed, validated, and reasoned about across runs - e.g. in CI or long-running agents. LSPs are query-oriented and ephemeral; they don’t give you a persistent artifact to assert against.

On breadth/noise: the intent isn’t to dump everything into one prompt. Output is sliced (per-folder / per-contract), and the assumption is that only relevant bundles are selected. Token minimization isn’t the primary goal; predictability and selectability are.

In practice I see them as complementary: LSPs for live search, generated contracts for ground truth. If your workflow is already LSP-driven, LogicStamp may simply not add much value - and that’s fine.

Yes. In the MCP setup the agent doesn’t decide to regenerate arbitrarily.

When stamp context --watch is active, the MCP server detects it. The agent first calls logicstamp_watch_status to see whether context is being kept fresh.

If watch mode is active, the agent can directly call list_bundles(projectPath) → read_bundle(projectPath) and will always read the latest regenerated output. No snapshot refresh is needed.

If watch mode isn’t active, the workflow falls back to refresh_snapshot → list_bundles → read_bundle.

So “consume” just means reading deterministic files via MCP tools, with watch mode ensuring those files stay up to date.

Adding a bit more context since I didn’t see your expanded comment at first:

AGENTS.md and LogicStamp aren’t mutually exclusive. AGENTS.md is great for manual, human-curated guidance. LogicStamp focuses on generated ground-truth contracts derived from the AST, which makes them diffable, CI-verifiable, and resistant to drift.

On token usage: the output is split into per-folder bundles, so you can feed only the slices you care about (or post-filter to exported symbols / public APIs). JSON adds some overhead, but the trade-off is reliable machine selectability and deterministic diffs.

Determinism here means: same repo state + config ⇒ identical bundle output.

Good question.

LogicStamp treats context as deterministic output derived from the codebase, not a mutable agent-side model.

When code changes mid-session, watch mode regenerates the affected bundles, and the agent consumes the latest output. This avoids desync by relying on regeneration rather than keeping long-lived agent state in sync.

I think this distinction matters less to users than to builders. From a user perspective, what’s novel here is policy and intent (no ads, no AI, privacy-first), not whether the index is first-party yet.

Many projects start as thin layers over existing infrastructure and only later take on the hard parts as resources allow. Being explicit about that roadmap feels like the right tradeoff early on.

One thing that seems under-discussed is what kind of state is worth persisting. Raw chat logs are cheap; distilled decisions, constraints, and preferences are harder but much more valuable.

Even if most approaches fail, exploring that boundary feels useful - especially if the system is transparent about what it stores and why.