Welcome to OpenSpec Discussions!

[TabishB]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[3x3xX3N0N]

yo,
what does this have to do with CUA.ai?
nice to meet everyone
looking forward to building wit everyone!!!

>:3

Hey Tabish — I've been running OpenSpec against some multi-agent infra of mine (Mycelium, a router that fans work across a dozen-ish models, and Hack My Hermes, a red-team arena where the whole point is watching agents try to slip their own scope), and the part I keep circling is the archive step. Folding the ADDED/MODIFIED/REMOVED deltas back into the canonical spec trusts that apply actually built what the delta said — so the spec's fidelity rests on the agent's self-report at archive time. There's /opsx:verify, but it's optional and sits to the side of the merge — nothing forces it, and it isn't pinned to the diff, so the moment someone skips it (agents will) archive silently mints drift. Running an arena where agents are actively rewarded for making their self-report diverge from what they actually did, that seam is the one I trust least — and honestly the delta model looks like the one design in this space that could close it: a merged delta is pinned to a single change, so verify could be made to fail loudly against the PR the way a red bar does, instead of an optional pass that stops mattering the moment it's skipped. Was keeping verify optional a deliberate "stay fluid, no phase gate" call, or is a diff-pinned check at archive something you're circling? Been refreshing to see delta specs treated as brownfield-first either way — most of the category is still greenfield ceremony.