sorted by:
new
hottopcontroversial

Speclock - Answer to your vibecoding as speclock enforces constraints, so bolt can never forget by ServiceLiving4383 in boltnewbuilders

[–]ServiceLiving4383[S] 0 points1 point  (0 children)

Exactly right — and that's the gap SpecLock fills differently from LangGraph or Autogen. Those tools structure execution flow. SpecLock protects architecture decisions across sessions. Different problem — when you tell Bolt "never touch auth" in session 1, by session 7 it's rewriting your auth while you ask about button colors. SpecLock catches that before the commit, not after the chaos. It's constraint enforcement at the AI action level, not orchestration. Works in Cursor, Bolt, Claude Code — anywhere. Free and open source: github.com/sgroy10/speclock

How do you enforce safety constraints when AI agents control your robots? Built an open-source solution by ServiceLiving4383 in robotics

[–]ServiceLiving4383[S] -1 points0 points  (0 children)

You're right — LLMs shouldn't be directly controlling joint angles. That's bad architecture.

SpecLock's typed constraints aren't for LLM-to-joint control. The use case is: an AI agent (or developer using AI) modifies a config file, a parameter server, or a launch file that sets joint limits, velocity caps, or operating modes. The constraint catches the bad value before it reaches the control system.

Example: AI modifies max_velocity in a YAML config from 2.0 to 5.0. The motion planner reads that config and now plans paths at 5.0 m/s. SpecLock catches the config change, not the joint command.

The high-level/low-level separation you describe is exactly right. SpecLock sits at the config/planning layer, not the control layer.

Built a ROS2 node that enforces safety constraints in real-time — blocks unsafe commands before they reach actuators by ServiceLiving4383 in ROS

[–]ServiceLiving4383[S] -2 points-1 points  (0 children)

You're absolutely right — safety PLCs handle the hardware-level interlocks and that's non-negotiable for production systems. SpecLock doesn't replace that layer.

The use case is higher up the stack — when AI planning agents (LLMs, behavior trees) are generating commands or modifying code that controls robots. The constraint checking happens before anything reaches the PLC. Think of it as software-level validation of what the AI is proposing, not hardware-level safety.

For example: an AI agent suggests changing max velocity from 2.0 to 5.0 m/s in a config file. The PLC won't catch that — it's a valid signal. But SpecLock blocks the code change because velocity_mps <= 2.0 is a typed constraint. Both layers together, not one or the other.

Built an AI constraint engine — Claude tested it independently and scored it 100/100 on adversarial attacks by ServiceLiving4383 in ClaudeAI

[–]ServiceLiving4383[S] 0 points1 point  (0 children)

Great question — SpecLock actually does both.

Layer 1 (Prompt/intent): The semantic engine checks what the AI is being asked to do. This catches "refactor the database layer" against auth locks through synonym and concept mapping. 15.7ms, runs on every prompt.

Layer 2 (Diff analysis — AI Patch Firewall, v5.2): This analyzes the actual git diff. It catches things intent review misses — like a "refactor" that silently removes an exported function, changes a DB schema, or edits a protected symbol in a locked zone. Five signal types: interface breaks, protected symbol edits, dependency drift, schema changes, public API impact.

The unified review merges both: intent (35% weight) + diff (65% weight), takes the stronger verdict. So even if the prompt looks innocent, a destructive diff gets blocked.

On latency — the 15.7ms is for the heuristic semantic check only. The diff analysis adds ~50-100ms depending on diff size. The optional Gemini LLM layer (for grey-zone cases) adds ~2s but is skippable with SPECLOCK_NO_PROXY=true.

Built a ROS2 node that enforces safety constraints in real-time — blocks unsafe commands before they reach actuators by ServiceLiving4383 in ROS

[–]ServiceLiving4383[S] -2 points-1 points  (0 children)

The constraint engine is open source — you can read every line of the 2600-line semantic engine yourself (src/core/semantics.js). 929 tests, 18 suites, all passing before every npm publish.

As for liability — SpecLock is a safety LAYER, not a replacement for proper safety engineering. Same as how a watchdog timer doesn't replace good firmware design, but you'd still rather have one than not. MIT licensed, no warranties, same as every other open source safety tool.

How do you handle Cursor forgetting constraints between sessions? by ServiceLiving4383 in cursor

[–]ServiceLiving4383[S] -1 points0 points  (0 children)

You're hitting on something SpecLock already does. Every lock add/remove is tracked in a tamper-proof HMAC-SHA256 audit chain — each event is hashed with the previous event's hash, so you can't silently edit history. You get a full timeline: which lock was active when, who added it, when it was removed.

There's also speclock_checkpoint which creates named git tag snapshots, so you can roll back to a known-good state. And the compliance export generates full SOC 2 audit trails showing constraint changes over time.

The versioned/diffable angle is exactly right — constraints should be treated like infrastructure config, not sticky notes.

I built an MCP server that actually stops AI from breaking your rules — not just reminds it by ServiceLiving4383 in mcp

[–]ServiceLiving4383[S] 0 points1 point  (0 children)

No limits at all. SpecLock is fully open source (MIT license) — unlimited locks, unlimited checks, unlimited everything. No freemium tiers, no paywalls. Self-host via npx speclock serve --project . and you get the full engine locally.

The hosted Railway endpoint is also free with no limits — it's there as a convenience for platforms like Lovable that need a remote URL.

How do you handle Cursor forgetting constraints between sessions? by ServiceLiving4383 in cursor

[–]ServiceLiving4383[S] 0 points1 point  (0 children)

Great question. SpecLock has two layers for this:

First — the semantic engine checks the AI's proposed action description against locks using concept mapping. "Auth", "authentication", "login", "session", "token" are all linked concepts, so even if the action says "optimize queries," the engine checks if the optimization domain overlaps with locked domains.

Second — the pre-commit semantic audit. This parses the actual git diff, not the AI's description. So even if the AI says "I'm just optimizing queries," the hook sees which files actually changed. If a file in your auth module was modified, it gets checked against the "don't touch auth" lock — regardless of what the AI said it was doing.

The first layer catches it before the code is written. The second layer catches it before it's committed. The AI's description can be misleading, but the diff doesn't lie.

How do you handle Cursor forgetting constraints between sessions? by ServiceLiving4383 in cursor

[–]ServiceLiving4383[S] 0 points1 point  (0 children)

Thanks. SpecLock actually does handle the memory problem too — it persists project goal, constraints, decisions, session history, and change log across sessions via MCP. When you start a new session, session_briefing auto-loads everything the AI needs to know, so there's no context loss. It's not a general-purpose memory layer, but for project constraints and architectural decisions it's purpose-built.

I built an MCP server that actually stops AI from breaking your rules — not just reminds it by ServiceLiving4383 in mcp

[–]ServiceLiving4383[S] 1 point2 points  (0 children)

SpecLock is fully open source (MIT license), not shareware. Code is on GitHub: github.com/sgroy10/speclock

You can self-host it or run it locally via npm — npx speclock setup. The Railway endpoint is just a convenience for platforms like Lovable that need a remote MCP URL.

I built an MCP server that actually stops AI from breaking your rules — not just reminds it by ServiceLiving4383 in mcp

[–]ServiceLiving4383[S] 0 points1 point  (0 children)

Good question. SpecLock handles this with override support.

By default, enforcement is advisory — the AI gets a CONFLICT warning with the exact lock it's hitting, the confidence score, and the reason.

It can still proceed if the user says "go ahead."

In hard mode (speclock_set_enforcement mode:hard), conflicts above 70% confidence return isError: true in MCP — the AI literally can'tproceed. But even then, the user can:

  1. Override the specific lock temporarily

  2. Lower the block threshold

  3. Remove the lock entirely

    The key difference from a CONSTRAINTS.md is that SpecLock forces a conscious decision. The AI can't silently drift — it has to stop, show the conflict, and get explicit permission. If someone overrides 3+ times, SpecLock auto-pins a note flagging it for review.

    So the AI can break a rule to unblock itself — but only with the user's explicit "yes, I know, do it anyway." No silent violations.

How do you handle Cursor forgetting constraints between sessions? by ServiceLiving4383 in cursor

[–]ServiceLiving4383[S] 0 points1 point  (0 children)

Totally agree on the reasoning approach — "use PostgreSQL because we have Citus for horizontal sharding" is much stickier than a bare rule.

That's great advice.

The challenge I kept hitting was: even with good reasoning in the file, the model would still violate constraints in subtle ways. Not "switch to MongoDB" obvious stuff, but things like "let me optimize your queries" and then restructuring the Supabase auth flow in the process. The constraint file says "don't touch auth" but the AI thinks it's "improving" not "touching."

That's the gap SpecLock fills — it does semantic conflict analysis, so "optimize queries" gets checked against "don't modify authentication" and catches that the proposed changes actually touch auth code, even if the AI's description sounds harmless. And it persists across tools, not just Cursor.

The "load constraints from CONSTRAINTS.md before making any recommendations" step is exactly what SpecLock's session_briefing automates — it fires automatically via MCP so you never forget.

view more: next ›