MUKE-coder/grit

Vision This is the killer feature. The next generation of frameworks (v0, Convex, base44) blur the line between "describe" and "build". Grit has a unique advantage: the codebase has strong conventions (TwoPane, drawer forms, RBAC, generators) that an AI can reliably extend. Proposal ``` grit describe "tenants need a vacation hold feature — they pause their booking for N days without paying, can extend by 7 days max, requires manager approval" ``` The CLI: Reads the existing schema + permission catalogue + AGENTS.md conventions Calls Claude with a structured prompt + the relevant codebase slice Proposes a plan: new models, new endpoints, new permissions, new UI sections, new tests User reviews + accepts → `grit generate` is invoked with the parsed plan Output is committed to a `grit/` branch with a generated PR description Critically: the framework's strict conventions (issues #18-#36) make AI output high-quality. Most AI scaffolders produce bespoke code; Grit's would produce code

Vision Every B2B SaaS app needs multi-tenancy. Today, retrofitting `org_id` into a single-tenant codebase is a 2-week migration that breaks everything. Get this right at scaffold time and it's free for life. Proposal `grit init --multi-tenant` (or a config flag) produces an app where: An `Organization` model + memberships table ships with the framework Every generated model has an `OrgID` FK (column + index) Every generated query is auto-scoped via a `gorm` global hook that reads `org_id` from the request context A `middleware.RequireOrg` extracts the active org from JWT / subdomain / custom resolver The frontend `` is part of the topbar Permissions can be org-scoped (a user can be ADMIN in org A and EMPLOYEE in org B) Migration helper: convert a single-tenant app to multi-tenant with one command Why this is differentiating Frameworks that bolt multi-tenancy on as an afterthought (most Go and Node frameworks) make every team rebuild this. Frameworks that bake it in (Salesforce-style,

Vision Even with type generation (#37), today you write a Go struct, a Zod schema for the form, a TS type for the API client, and validator tags for the request binding. That's 4 places where one fact lives. The frameworks that win in the next 5 years will collapse this. Encore does it for Go. Convex does it for JS. Grit should do both — same schema, both runtimes. Proposal A schema DSL (`.grit.schema` files or annotated Go) that becomes the single source of truth: ```grit resource Tenant { field name string @required field phone string @required @Format("phone") field email string? @Format("email") field tenant_type enum("shop", "apartment") field is_vip bool @default(false) field monthly_rent money @Currency("UGX") } ``` Generates: `Tenant` Go struct with GORM tags + binding tags `Tenant` TS interface `TenantSchema` Zod schema for forms OpenAPI component Permission seed entries (`tenants.create`, `tenants.read`, …) Activity-log registration Why th

Vision The biggest productivity gap in any Go + TS stack is the type seam. Every team writes the Go struct, then writes the TS interface, then waits for production to find the drift. Frameworks that close this gap (tRPC for Node, Encore for Go) are universally loved by their users. Grit should ship this from day one. Proposal A code generator that reads handler signatures and produces: TypeScript interfaces for every `json` tag in models + request/response structs A typed API client (`api.tenants.list({ search: "abc" })` with autocomplete + return-type inference) Zod schemas mirroring the Go `binding:"required"` / validator tags OpenAPI 3.1 spec as a free byproduct Triggered by `grit generate types` or watched in `grit dev`. Output goes to `packages/shared` so web + admin + desktop + expo all consume the same contracts. Why this is differentiating No more "it worked in Postman, broke in prod" Refactor-safe: rename a Go field, the TS call site fails to compile API docs come for free