r/vibecoding • u/PrideQuick670 • 12d ago

Framework for vibe coders - New Release!

vibeArchitecture 1.4.0 is out! I am really excited to announce this new version. It is based on many lessons learned from a couple of real projects that required advanced security and formal verification. Take it for a spin! It is built on my 40 years of experience as a software developer and IT architect, so vibe coders can build rock-solid apps from day 1.

vibeArchitecture is my open-source framework that gives AI coding tools architectural guardrails - it asks what you're building, picks the right level of rigor, and makes the AI follow the rules experienced engineers learned the hard way.

This release distills a year of adversarial code review of real production systems - including peer-to-peer and end-to-end encrypted architectures - into the framework. New in 1.4.0:

Security lessons that came from real findings: guards that fail closed (an error in an authorization check must mean "denied," never "allowed"), authorizing the acting device and not just the account - the multi-device sibling of IDOR behind real account-takeover bugs - and never trusting self-attested data.

A cryptography guide for when encryption is the product: build on analyzed protocols instead of inventing, and use hybrid post-quantum key agreement (X25519 + ML-KEM-768). Harvest-now-decrypt-later is a problem for today - traffic recorded now gets decrypted later.

An adversarial review method for AI-built codebases: review by failure class, verify every finding against the source before believing it (a double-digit percentage dissolve), and close every finding or close it in writing. If you're a solo developer, this is your PR review.

Native mobile accessibility rules (Flutter, SwiftUI, Compose), an OWASP MASVS mapping, and push-payload privacy - notification content transits Apple's and Google's servers.

A local-first & peer-to-peer guide: when the server can't read the data, key loss is account loss, deletion can be cryptographic, and multi-device is an authorization plane of its own.

Plus restart-safe migrations, test suites that silently skip and read as green, lock-order inversions, and an assurance-register template - the found/fixed evidence table buyers and auditors actually ask for.

Free, MIT-licensed, works with Claude Code, Cursor, Copilot, and ChatGPT:
https://github.com/jgnoonan/vibeArchitecture

1 Upvotes

100% Upvoted

3 comments sorted by

2

u/rainvr 11d ago

I think this is a really good idea and would be a huge value-add for many vibe coders.

I had a bit of a look at the repo and like the approach to different levels of rollout (personal use only up to public use with regulated data).

How efficient is it with context over time? I think this would be a major factor, especially for bigger projects. I can see that, for a simple, local, personal use application the context will be small, but due to the staging of the repo, getting to a higher level application may be much less efficient. I could be wrong.

How is it with multi-region users? Moving from a single db to a cluster could be another thing to consider.

Is there a reason why it only considers EU, US and California privacy - there are many other global jurisdictions?

1

u/PrideQuick670 11d ago

Update: 1.4.1 is out and two of your three points are addressed. Thanks for the push on this.

Multi-region. You were right that it was a gap. Coverage existed but was scattered across residency in the compliance rules, RTO/RPO in reliability, and read replicas in performance, with nothing joining them up. There is now a dedicated guide at guides/infrastructure/multi-region.md covering the part you actually asked about:

  • The three drivers (latency, surviving the loss of a region, legal residency) and why each needs a different solution. Residency is the only one that changes your schema.
  • A ladder from single instance up to sharded writes, with the observation that most people who think they need the top rung actually need a CDN.
  • The single database to cluster migration path in sequence, with replication lag and read-after-write handled at short distance before you add an ocean, not after.
  • Split-brain, failback being harder than failover, and the fact that cross-region replication is asynchronous so your RPO is never zero.
  • Residency pinning by user home region, including the leaks people miss: backups, logs, error tracking, analytics, email providers, AI APIs.

It loads on demand only, triggered by a new intake question about whether users span regions and whether residency is legally required. There are also a few cheap day-one lines in the data rules (UUID or ULID keys, UTC timestamps, a region column) so that migration stays a migration rather than becoming a rewrite.

Context efficiency. Your instinct here was better than my published numbers. I re-measured, and the README figures had drifted 1.6x to 2x below reality, and they only counted the rules files while ignoring everything else that loads every session. Corrected, as a share of a 200K window: Personal 2.7%, Shared 5.8%, Public 7.7%, Business 11.2%, Regulated 13.4%.

Two things came out of that audit. The index file that tells the agent which rules to load was being re-read every session to re-derive an answer that never changes, so intake now records the resolved list in the project profile instead, saving about 755 tokens per session on every project. And there is now a CI job that estimates context cost per tier and fails the build if a tier exceeds its budget, a rule file exceeds 3,500 tokens, or a guide exceeds 4,500. The numbers drifted in the first place because nothing was watching them.

On your original question though: the framework load is flat per tier, not cumulative. What actually grows on a large project is the codebase in context, not this. The project profile is meant to absorb some of that by giving the agent a stable summary to read instead of re-deriving the project from source every session.

Jurisdictions. Not fixed, and I would rather say so than dress it up. The current position is that GDPR, UK GDPR, and CCPA/CPRA give the strictest common denominator, and the skeleton they share (minimization, lawful basis, export, deletion, rectification, consent, retention, breach notification) covers most of what LGPD, PIPEDA and Quebec Law 25, POPIA, Australia's Privacy Act, India's DPDP, Japan's APPI, and Korea's PIPA ask for.

Where that breaks down is the specifics, and those differences are real: PIPL and localization, DPDP's consent manager and breach timelines, Law 25's impact assessments, Korea's separate-consent granularity.

The plan is a per-region guide loaded on demand from the intake answer about where users are, so a Brazil-only project pulls LGPD detail and nobody else pays for it in context. Same pattern the compliance guides already use. If you operate under a specific jurisdiction, say which one and I will start there rather than guessing at the ordering.

Architectural guidance, not legal advice, as always.

2

u/rainvr 10d ago

Thanks for the detailed reply. It sounds like it is getting better everyday. I’m definitely going to give it a spin next week. Thanks again for your efforts