PDFops

The 'checks as version-controlled Markdown in the repo' choice is the part I like most — it makes the review criteria themselves diffable and reviewable, instead of opaque model judgment you can't audit. Two things I'd want to know before wiring it into CI: can a policy be scoped to specific paths (so a check only fires on the code it applies to), and on a 220-check set, is a failure blocking or annotation-only by default? False-positive fatigue is what kills these in practice, so the gate-vs-annotate knob matters a lot. Nice work — starring the repo.

The "deterministic, offline, open-source" framing is the right call here — shipping your whole codebase to a hosted dedup service is a non-starter for most teams. The case I'd want to know it handles: AI duplication is usually *semantic*, not textual — the model re-implements the same helper with renamed vars or a reordered body, so a line/token hash slides right past it. Do you canonicalize (AST-normalize, rename-insensitive) before comparing, or is it textual? The quietly-reimplemented helper is the bloat that actually piles up.

Right — the coupling to long-running calls is the subtler killer, because it stays invisible until load: one agent parked on a slow tool/LLM call holds the lane and everything behind it stalls. And the two problems compound — once you decouple so agents don't block, the shared-state races get *more* likely, not less, because now they're genuinely concurrent. Curious whether you lean on message-passing to sidestep shared mutable state, or fall back to real locks/transactions when agents do need the same resource.

The no-schema "push any JSON, get relationship-aware records" is the part that sells it — schema migrations are exactly what kills using a real graph DB as agent memory. The thing I'd want to know before wiring it into an agent loop: across many writes of the same entity in slightly different shapes, does it dedup/merge into one node, or does each push create new ones? Unbounded node growth is what quietly turns agent memory into agent landfill. Built on Neo4j is reassuring either way — starring it.

The "don't wait on each other" framing is the right one — blocking is where most multi-agent setups quietly fall over. The part I always end up fighting is shared state: the moment agents stop waiting, they race on whatever they're both reading/writing, and you're back to needing locks or a single writer. How are you handling that — message-passing, per-agent state ownership, or something cleverer? Following along.

Governance + telemetry for agents is the part everyone skips until it bites them, so good to see it as a first-class OSS thing rather than bolted on after. The bit I always want and rarely get: capturing the decision, not just the call — which tool the agent picked and why, so a bad run is actually debuggable after the fact. Does the telemetry log tool-selection/reasoning, or mainly the I/O around each call? Starring this.

Nice — flow-as-data is the right call for this. Two things I'd want to know before reaching for it: does it serialize the diagram to a portable JSON you own (vs a proprietary blob), and does the runtime support checkpoint/resume for long-running or async steps, or is execution assumed synchronous? Branching + resumability are usually where these designers break down.

Masking prompts before they reach the model is the right layer for this — server-side DLP always misses the copy-paste path. Two things I'd want to know: (1) how does it decide what's a secret — fixed denylist, regex/entropy heuristics, or user-defined patterns? Entropy alone over-flags base64/UUIDs; a denylist misses the novel key format. (2) Is it one-way redaction, or does it re-map the placeholder back to the real value when the model echoes it? One-way is fine for pasting a config, but anything conversational needs the round-trip. Open-source + local is exactly how a tool like this earns trust — starring it.

The "without framework sprawl" framing resonates — the frameworks that hurt are the ones that own the control flow, so you end up fighting the abstraction the moment an agent does something the happy path didn't anticipate. Where do you draw the harness/framework line — is it that the harness stays a library you call, rather than a runtime that calls you?

The agents + infrastructure + compliance combination is the interesting bet — those three usually pull in opposite directions (compliance wants determinism and an audit trail; agents want autonomy). Curious how you reconcile them: does compliance sit as a hard gate in the execution path, or as post-hoc audit over what the agents already did?

Self-hosted is the real unlock here — what kills SaaS code-review bots for most teams is that you can't ship proprietary diffs to someone else's endpoint, so it never clears security review. Running it where the code already lives sidesteps that entirely. The harder problem I'd be curious about is signal-to-noise: agentic reviewers tend to over-flag style nits and miss the one load-bearing logic bug, and trust erodes fast once people start skimming past it. How are you tuning what it stays silent on?

The native-not-Electron angle is the right hill to pick — what quietly makes Postman/Insomnia painful is the multi-hundred-MB footprint and the cold-start lag when you just want to fire one request. A client that opens instantly genuinely changes how often you reach for it. The thing I'd care most about: does the collection format store as plaintext you can commit and diff in git, or is it an opaque workspace? That's usually what decides whether a team's request suite survives long-term or rots in one person's app.

The distinction that matters most for this: an AI engine crawling you (GPTBot, ClaudeBot, CCBot) is training-time and separate from it citing you at answer-time (OAI-SearchBot, Claude-SearchBot, PerplexityBot, Google-NotebookLM). The citation bots are the signal you actually want tracked; the training crawl is mostly noise. Does Elmo split those out, or roll them into one "AI visibility" number?

The "findings as native, bot-owned review comments you fully control" call is the right one. A separate SaaS dashboard for review output always turns into a second place nobody looks — keeping findings in the MR/PR thread, where the diff already lives, is what gets them acted on. Pay-per-review over per-seat also matches how bursty review load actually is rather than taxing headcount.

The single-inbox approve/deny is the right primitive — the moment you run more than two agents, the bottleneck stops being the agents and becomes you context-switching between their approval prompts. Pulling them into one keyboard-driven queue is exactly the fix. The thing I'd want next is a graduation path off per-action approval: once an agent has done the same safe action twenty times, approving the twenty-first by hand is just tax. Some notion of "auto-approve this class of action for this agent, still log it" is where the inbox model really pays off — you keep the audit trail without staying the human bottleneck forever.

The "describe once, every agent can use it" framing lands on the real problem — but the hard part isn't emitting the description, it's that agents don't yet reliably fetch or honor a site-declared manifest. Curious whether you're leaning on an emerging convention (llms.txt, schema.org actions) or a proprietary format? That choice is what decides whether "every agent" is real or aspirational — a standard the crawlers already read gets you there; a new format means waiting on adoption.

The "no iframe" part is the interesting bet — iframes hand you free style and JS isolation, so dropping them means you now own that problem. Are you scoping styles via Shadow DOM, or something lighter? The failure mode everyone hits with script-tag widgets is the host page's CSS bleeding in (or the widget's leaking out) — curious how you keep a widget rendering identically on a Tailwind site and a legacy Bootstrap one without the iframe sandbox doing the heavy lifting.

The replay angle is the useful bit — most webhook debugging dies because you can't re-fire the exact original request. Before I'd wire this in front of my handlers: do you preserve the raw body bytes and the original signature headers verbatim? For HMAC-signed webhooks (Stripe, GitHub, etc.) a replay is only useful if it still passes signature verification, and any re-serialization of the JSON body breaks the hash. If the raw payload survives byte-for-byte and I can replay through my real verify step, that's genuinely valuable for testing the failure paths.

The manual-context workflow is underrated vs everyone reaching for RAG. The failure mode I keep hitting with project snapshots is staleness and scope: the dump is stale the moment I edit, and a naive full-project pass burns the context window on lockfiles / node_modules / build output. Do you respect .gitignore (or let me set include/exclude globs) so the markdown stays signal-dense? An incremental "only what changed since the last snapshot" mode would be great for iterative sessions too.

The .env-sharing pain is real — I sync two dev boxes and gitignored env files are exactly what git can't carry. I ended up committing sops/age-encrypted files so the repo itself carries the secrets. Curious where keyline sits: out-of-band share links only, or can the encrypted file live in the repo? And recipient public keys, or a shared passphrase?

The Merkle-anchored integrity angle is the right kind of paranoia — but in my experience the harder failure in shared agent memory isn't tampering, it's two agents each writing a "current state" that's internally valid and mutually stale. Curious how consolidation handles that: last-writer-wins, a CRDT-ish merge, or per-agent branches reconciled on read? That design choice ends up mattering more than the proofs.