朱子纯 / vibe-erp

Commit 95b26a882d57fe81ab7d03fc539e3a58de0b81bc

Authored by vibe_erp
1 parent 1ead32d7

docs: align with code state — add PROGRESS.md, refresh README + CLAUDE + guides 

The README and CLAUDE.md "Repository state" sections were both stale —
they still claimed "v0.1 skeleton, one PBC implemented" and "no source
code yet" when in reality the framework is at v0.6+P1.5 with 92 unit
tests, 11 modules, 7 cross-cutting platform services live, 2 PBCs, and
a real customer-style plug-in serving HTTP from its own DB tables.

What landed:

* New PROGRESS.md at the repo root. Single-page progress tracker that
  enumerates every implementation-plan unit (P1.x, P2.x, P3.x, P4.x,
  P5.x, R, REF.x, H/A/M.x) with status badges, commit refs for the
  done units, and the "next priority" call. Includes a snapshot table
  (modules / tests / PBCs / plug-ins / cross-cutting services), a
  "what's live right now" table per service, a "what the reference
  plug-in proves end-to-end" walkthrough, the "what's not yet live"
  deferred list, and a "how to run what exists today" runbook.

* README.md "Building" + "Status" rewritten. Drops the obsolete
  "v0.1 skeleton" claim. New status table shows current counts.
  Adds the dev workflow (`installToDev` → `bootRun`) and points at
  PROGRESS.md for the per-feature view.

* CLAUDE.md "Repository state" section rewritten from "no source
  code, build system, package manifest, test suite, or CI yet" to
  the actual current state: 11 subprojects, 92 tests, 7 services
  live, 2 PBCs, build commands, package root, and a pointer at
  PROGRESS.md.

* docs/customer-onboarding/guide.md, docs/workflow-authoring/guide.md,
  docs/form-authoring/guide.md: replaced "v0.1: API only" annotations
  with "current: API only". The version label was conflating
  "the v0.1 skeleton" with "the current build" — accurate in spirit
  (the UI layer still hasn't shipped) but misleading when readers
  see the framework is on commit 18, not commit 1. Pointed each
  guide at PROGRESS.md for live status.

Build: ./gradlew build still green (no source touched, but verified
that nothing in the docs change broke anything).

The deeper how-to docs (architecture/overview.md, plugin-api/overview.md,
plugin-author/getting-started.md, i18n/guide.md, docs/index.md) were
left as-is. They describe HOW the framework is supposed to work
architecturally, and the architecture has not changed. Only the
status / version / scope statements needed updating.
Inline Side-by-side
Showing 6 changed files with 270 additions and 18 deletions
CLAUDE.md
  View file @95b26a8
@@ -93,9 +93,19 @@ plugins (incl. ref) depend on: api/api-v1 only @@ -93,9 +93,19 @@ plugins (incl. ref) depend on: api/api-v1 only
93 93
94 ## Repository state 94 ## Repository state
95 95
96 -The repository currently contains the reference business documents under `raw/`, this `CLAUDE.md`, and the architecture spec at `docs/superpowers/specs/2026-04-07-vibe-erp-architecture-design.md`. **There is no source code, build system, package manifest, test suite, or CI configuration yet.** The next concrete step is an implementation plan, then bootstrapping the Gradle multi-project skeleton.  
97 -  
98 -When source code is added, this file should be updated with: build/test/lint commands, the actual package name root (`org.vibeerp` is assumed but not yet committed), and any deviations from the design spec. 96 +**Foundation complete; first business surface in place.** As of the latest commit:
  97 +
  98 +- **11 Gradle subprojects** built and tested. The dependency rule (PBCs never import each other; plug-ins only see `api.v1`) is enforced at configuration time by the root `build.gradle.kts`.
  99 +- **92 unit tests across 11 modules**, all green. `./gradlew build` is the canonical full build.
  100 +- **All 7 cross-cutting platform services live and smoke-tested end-to-end** against real Postgres: auth (P4.1), plug-in HTTP endpoints (P1.3), plug-in linter (P1.2), plug-in-owned Liquibase + typed SQL (P1.4), event bus + transactional outbox (P1.7), metadata loader (P1.5), plus the audit/principal context bridge.
  101 +- **2 of 10 core PBCs implemented end-to-end** (`pbc-identity`, `pbc-catalog`) — they validate the recipe every future PBC clones.
  102 +- **Reference printing-shop plug-in** owns its own DB schema, CRUDs plates and ink recipes via REST through `context.jdbc`, ships its own metadata YAML, and registers 7 HTTP endpoints. It is the executable acceptance test for the framework.
  103 +- **Package root** is `org.vibeerp`.
  104 +- **Build commands:** `./gradlew build` (full), `./gradlew test` (unit tests), `./gradlew :distribution:bootRun` (run dev profile, stages plug-in JAR automatically), `docker compose up -d db` (Postgres). The bootstrap admin password is printed to the application logs on first boot.
  105 +- **Documentation:** site under `docs/`. Architecture spec and implementation plan under `docs/superpowers/specs/`. Live progress tracker in [`PROGRESS.md`](PROGRESS.md).
  106 +- **Pushed to** https://github.com/reporkey/vibe-erp with GitHub Actions CI on every commit.
  107 +
  108 +For the per-unit status of every implementation plan item and the list of deferred work, see [`PROGRESS.md`](PROGRESS.md).
99 109
100 ## What to do when asked to "just add" a printing-specific feature 110 ## What to do when asked to "just add" a printing-specific feature
101 111
PROGRESS.md 0 → 100644
  View file @95b26a8
  1 +# vibe_erp — Project Progress
  2 +
  3 +> Snapshot of where the framework stands today, what's done, and what's next.
  4 +> The detailed plan of record is
  5 +> [`docs/superpowers/specs/2026-04-07-vibe-erp-implementation-plan.md`](docs/superpowers/specs/2026-04-07-vibe-erp-implementation-plan.md).
  6 +> The architecture is locked in
  7 +> [`docs/superpowers/specs/2026-04-07-vibe-erp-architecture-design.md`](docs/superpowers/specs/2026-04-07-vibe-erp-architecture-design.md).
  8 +
  9 +## At a glance
  10 +
  11 +| | |
  12 +|---|---|
  13 +| **Latest version** | v0.6 (post-P1.5) |
  14 +| **Latest commit** | `1ead32d feat(metadata): P1.5 — metadata store seeding` |
  15 +| **Repo** | https://github.com/reporkey/vibe-erp |
  16 +| **Modules** | 11 |
  17 +| **Unit tests** | 92, all green |
  18 +| **End-to-end smoke runs** | All cross-cutting services verified against real Postgres |
  19 +| **Real PBCs implemented** | 2 of 10 (`pbc-identity`, `pbc-catalog`) |
  20 +| **Plug-ins serving HTTP** | 1 (reference printing-shop, 7 endpoints + own DB schema + own metadata) |
  21 +| **Production-ready?** | **No.** Foundation is solid; many capabilities still deferred. |
  22 +
  23 +## Current stage
  24 +
  25 +**Foundation complete; first business surface in place.** All seven cross-cutting platform services that PBCs and plug-ins depend on are now live (auth, plug-in lifecycle, plug-in HTTP, plug-in linter, plug-in DB schemas, event bus + outbox, metadata loader). Two real PBCs validate the modular-monolith template. The reference printing-shop plug-in has graduated from "hello world" to a real customer demonstration: it owns its own DB schema, CRUDs its own domain through the api.v1 typed-SQL surface, registers its own HTTP endpoints, and would be rejected at install time if it tried to import any internal framework class.
  26 +
  27 +The next phase is **building business surface area**: more PBCs (partners, inventory, sales orders), the workflow engine (Flowable), the metadata-driven custom fields and forms layer (Tier 1 customization), and eventually the React SPA.
  28 +
  29 +## Total scope (the v1.0 cut line)
  30 +
  31 +The framework reaches v1.0 when, on a fresh Postgres, an operator can `docker run` the image, log in, drop a customer plug-in JAR into `./plugins/`, restart, and walk a real workflow end-to-end without writing any code — and the **same** image, against a different Postgres pointed at a different company, also serves a different customer with a different plug-in. See the implementation plan for the full v1.0 acceptance bar.
  32 +
  33 +That target breaks down into roughly 30 work units across 8 phases. About **15 are done** as of today. Below is the full list with status.
  34 +
  35 +### Phase 1 — Platform completion (foundation)
  36 +
  37 +| # | Unit | Status |
  38 +|---|---|---|
  39 +| ~~P1.1~~ | ~~Postgres RLS transaction hook~~ | **N/A** — removed by single-tenant refactor |
  40 +| P1.2 | Plug-in linter (ASM bytecode scan) | ✅ DONE — `7af11f2` |
  41 +| P1.3 | Plug-in lifecycle: HTTP endpoints, DefaultPluginContext, dispatcher | ✅ DONE — `20d7ddc` |
  42 +| P1.4 | Plug-in Liquibase application + `PluginJdbc` | ✅ DONE — `7af11f2` |
  43 +| P1.5 | Metadata store seeding | ✅ DONE — `1ead32d` |
  44 +| P1.6 | ICU4J `Translator` implementation + locale resolution | ⏳ Next priority |
  45 +| P1.7 | Event bus + transactional outbox | ✅ DONE — `c2f2314` |
  46 +| P1.8 | JasperReports integration | 🔜 Pending |
  47 +| P1.9 | File store (local + S3) | 🔜 Pending |
  48 +| P1.10 | Job scheduler (Quartz) | 🔜 Pending |
  49 +
  50 +### Phase 2 — Embedded workflow engine
  51 +
  52 +| # | Unit | Status |
  53 +|---|---|---|
  54 +| P2.1 | Embedded Flowable (BPMN 2.0) + `TaskHandler` wiring | 🔜 Pending |
  55 +| P2.2 | BPMN designer (web) | 🔜 Pending — depends on R1 |
  56 +| P2.3 | User-task form rendering | 🔜 Pending |
  57 +
  58 +### Phase 3 — Metadata store: forms and rules (Tier 1 customization)
  59 +
  60 +| # | Unit | Status |
  61 +|---|---|---|
  62 +| P3.1 | JSON Schema form renderer (server) | 🔜 Pending |
  63 +| P3.2 | Form renderer (web) | 🔜 Pending — depends on R1 |
  64 +| P3.3 | Form designer (web) | 🔜 Pending — depends on R1 |
  65 +| P3.4 | Custom field application (JSONB `ext` validation) | ⏳ Next priority candidate |
  66 +| P3.5 | Rules engine (event-driven) | 🔜 Pending |
  67 +| P3.6 | List view designer (web) | 🔜 Pending — depends on R1 |
  68 +
  69 +### Phase 4 — Authentication and authorization
  70 +
  71 +| # | Unit | Status |
  72 +|---|---|---|
  73 +| P4.1 | Built-in JWT auth + Argon2id + bootstrap admin | ✅ DONE — `540d916` |
  74 +| P4.2 | OIDC integration (Keycloak-compatible) | 🔜 Pending |
  75 +| P4.3 | Permission checking against `metadata__role_permission` | 🔜 Pending |
  76 +
  77 +### Phase 5 — Core PBCs
  78 +
  79 +| # | Unit | Status |
  80 +|---|---|---|
  81 +| P5.1 | `pbc-catalog` — items, units of measure | ✅ DONE — `69f3daa` |
  82 +| P5.2 | `pbc-partners` — customers, suppliers, contacts | ⏳ Next priority candidate |
  83 +| P5.3 | `pbc-inventory` — stock items, lots, locations, movements | 🔜 Pending |
  84 +| P5.4 | `pbc-warehousing` — receipts, picks, transfers, counts | 🔜 Pending |
  85 +| P5.5 | `pbc-orders-sales` — quotes, sales orders, deliveries | 🔜 Pending |
  86 +| P5.6 | `pbc-orders-purchase` — RFQs, POs, receipts | 🔜 Pending |
  87 +| P5.7 | `pbc-production` — work orders, routings, operations | 🔜 Pending |
  88 +| P5.8 | `pbc-quality` — inspection plans, results, holds | 🔜 Pending |
  89 +| P5.9 | `pbc-finance` — GL, journal entries, AR/AP minimal | 🔜 Pending |
  90 +
  91 +### Phase 6 — Web SPA (React + TS)
  92 +
  93 +| # | Unit | Status |
  94 +|---|---|---|
  95 +| R1 | Vite + React + TS bootstrap, login flow, OpenAPI client | 🔜 Pending |
  96 +| R2 | Identity screens | 🔜 Pending |
  97 +| R3 | Customize / metadata UIs | 🔜 Pending |
  98 +| R4 | Per-PBC list/detail/create/edit screens | 🔜 Pending |
  99 +
  100 +### Phase 7 — Reference printing-shop plug-in
  101 +
  102 +| # | Unit | Status |
  103 +|---|---|---|
  104 +| REF.0 | Hello-world plug-in (PF4J + Plugin lifecycle + endpoints + own DB) | ✅ DONE through v0.6 |
  105 +| REF.1 | Real BPMN workflow handler (quote → job card) | 🔜 Pending — depends on P2.1 |
  106 +| REF.2 | Plate / ink / press CRUD as customer-style domain | ✅ Partial — plate + ink CRUD live (`7af11f2`) |
  107 +| REF.3 | Reference forms + automation rules in plug-in metadata | 🔜 Pending — depends on P3.3, P3.4 |
  108 +
  109 +### Phase 8 — Hosted, AI agents, mobile (post-v1.0)
  110 +
  111 +| # | Unit | Status |
  112 +|---|---|---|
  113 +| H1 | Instance provisioning console (one process per customer) | 🔜 Post-v1.0 |
  114 +| A1 | MCP server (REST endpoints exposed as AI-agent functions) | 🔜 v1.1 |
  115 +| M1 | React Native skeleton | 🔜 v2 |
  116 +
  117 +## What's live right now
  118 +
  119 +These are the cross-cutting platform services already wired into the running framework. Each was built with a real end-to-end smoke test against a Postgres container.
  120 +
  121 +| Service | Module | What it does |
  122 +|---|---|---|
  123 +| **Auth** (P4.1) | `platform-security`, `pbc-identity` | Username/password login → HMAC-SHA256 JWT (15min access + 7d refresh). Bootstrap admin printed to logs on first boot. Spring Security filter chain enforces auth on every endpoint except `/actuator/health`, `/api/v1/_meta/**`, `/api/v1/auth/login`, `/api/v1/auth/refresh`. Principal bridges into the audit listener so `created_by` columns carry real user UUIDs. |
  124 +| **Plug-in HTTP** (P1.3) | `platform-plugins` | Plug-ins call `context.endpoints.register(method, path, handler)` to mount lambdas under `/api/v1/plugins/<plugin-id>/<path>`. Path templates with `{var}` extraction via Spring's `AntPathMatcher`. Plug-in code never imports Spring MVC types. |
  125 +| **Plug-in linter** (P1.2) | `platform-plugins` | At plug-in load time (before any plug-in code runs), ASM-walks every `.class` entry for references to `org.vibeerp.platform.*` or `org.vibeerp.pbc.*`. Forbidden references unload the plug-in with a per-class violation report. |
  126 +| **Plug-in DB schemas** (P1.4) | `platform-plugins` | Each plug-in ships its own `META-INF/vibe-erp/db/changelog.xml`. The host's `PluginLiquibaseRunner` applies it against the shared host datasource at plug-in start. Plug-ins query their own tables via the api.v1 `PluginJdbc` typed-SQL surface — no Spring or Hibernate types ever leak. |
  127 +| **Event bus + outbox** (P1.7) | `platform-events` | Synchronous in-process delivery PLUS a transactional outbox row in the same DB transaction. `Propagation.MANDATORY` so the bus refuses to publish outside an active transaction (no publish-and-rollback leaks). `OutboxPoller` flips PENDING → DISPATCHED every 5s. Wildcard `**` topic for the audit subscriber; topic-string and class-based subscribe. |
  128 +| **Metadata loader** (P1.5) | `platform-metadata` | Walks the host classpath and each plug-in JAR for `META-INF/vibe-erp/metadata/*.yml`, upserts entities/permissions/menus into `metadata__*` tables tagged by source. Idempotent (delete-by-source then insert). User-edited metadata (`source='user'`) is never touched. Public `GET /api/v1/_meta/metadata` returns the full set for SPA + AI-agent + OpenAPI introspection. |
  129 +| **PBC pattern** (P5.x recipe) | `pbc-identity`, `pbc-catalog` | Two real PBCs prove the recipe: domain entity extending `AuditedJpaEntity` → Spring Data JPA repository → application service → REST controller under `/api/v1/<pbc>/<resource>` → cross-PBC facade in `api.v1.ext.<pbc>` → adapter implementation. Architecture rule enforced by the Gradle build: PBCs never import each other, never import `platform-bootstrap`. |
  130 +
  131 +## What the reference plug-in proves end-to-end
  132 +
  133 +The printing-shop reference plug-in is the framework's executable acceptance test. As of `1ead32d` it demonstrates **everything a real customer plug-in needs** except workflow handling:
  134 +
  135 +```
  136 +Plug-in JAR drop → host bootstrap:
  137 + 1. PF4J discovers the JAR and reads plugin.yml
  138 + 2. PluginLinter ASM-walks every class — passes
  139 + 3. PluginLiquibaseRunner applies META-INF/vibe-erp/db/changelog.xml
  140 + → creates plugin_printingshop__plate, plugin_printingshop__ink_recipe
  141 + 4. MetadataLoader.loadFromPluginJar reads
  142 + META-INF/vibe-erp/metadata/printing-shop.yml
  143 + → 2 entities, 5 permissions, 2 menus tagged source='plugin:printing-shop'
  144 + 5. VibeErpPluginManager calls Plugin.start(context) with a real
  145 + PluginContext (logger + endpoints + eventBus + jdbc all wired)
  146 + 6. The plug-in's start() lambda registers 7 HTTP endpoints
  147 + 7. Boot completes, app is serving traffic
  148 +
  149 +Live HTTP traffic:
  150 + POST /api/v1/auth/login (admin) → 200, JWT
  151 + POST /api/v1/plugins/printing-shop/plates (Bearer) → 201, plate created
  152 + GET /api/v1/plugins/printing-shop/plates → list of plates
  153 + GET /api/v1/plugins/printing-shop/plates/{id} → fetch by id
  154 + POST /api/v1/plugins/printing-shop/inks → 201, ink created
  155 + GET /api/v1/_meta/metadata → all 6 entities + 18 permissions
  156 + GET /api/v1/identity/users (Bearer) → still works
  157 + GET /api/v1/catalog/uoms (Bearer) → 15 seeded UoMs
  158 +```
  159 +
  160 +This is **real**: a JAR file dropped into a directory, loaded by the framework, executing customer-specific business logic against its own database tables, exposed via REST. The plug-in code never imports a single internal framework class — and the linter would refuse to load it if it tried.
  161 +
  162 +## What's not yet live (the deferred list)
  163 +
  164 +- **Workflow engine.** No Flowable yet. The api.v1 `TaskHandler` interface exists; the runtime that calls it doesn't.
  165 +- **i18n / Translator.** Plug-ins that try to use `context.translator` get an `UnsupportedOperationException` — the stub points at P1.6.
  166 +- **Custom fields.** The `ext jsonb` columns exist on every entity; the metadata describing them exists; the validator that enforces them on save does not (P3.4).
  167 +- **Forms.** No JSON Schema form renderer (server or client). No form designer.
  168 +- **Reports.** No JasperReports.
  169 +- **File store.** No abstraction; no S3 backend.
  170 +- **Job scheduler.** No Quartz. Periodic jobs don't have a home.
  171 +- **OIDC.** Built-in JWT only. OIDC client (Keycloak-compatible) is P4.2.
  172 +- **Permission checks.** `Principal` is bound; `metadata__permission` is seeded; the actual `@RequirePermission` enforcement layer is P4.3.
  173 +- **More PBCs.** Only identity and catalog exist. Partners, inventory, warehousing, orders, production, quality, finance are all pending.
  174 +- **Web SPA.** No React app. The framework is API-only today.
  175 +- **MCP server.** The architecture leaves room for it; the implementation is v1.1.
  176 +- **Mobile.** v2.
  177 +
  178 +## How to run what exists today
  179 +
  180 +```bash
  181 +# Bring up Postgres + the plug-in JAR (in background)
  182 +docker compose up -d db
  183 +./gradlew :reference-customer:plugin-printing-shop:installToDev
  184 +
  185 +# Boot the framework against it
  186 +./gradlew :distribution:bootRun
  187 +
  188 +# In another shell:
  189 +curl -s localhost:8080/api/v1/_meta/info
  190 +curl -s localhost:8080/api/v1/_meta/metadata | jq
  191 +
  192 +# Read the bootstrap admin password from the boot logs, then:
  193 +ACCESS=$(curl -s -H 'Content-Type: application/json' \
  194 + -X POST localhost:8080/api/v1/auth/login \
  195 + -d '{"username":"admin","password":"<from-logs>"}' | jq -r .accessToken)
  196 +
  197 +curl -s -H "Authorization: Bearer $ACCESS" localhost:8080/api/v1/identity/users
  198 +curl -s -H "Authorization: Bearer $ACCESS" localhost:8080/api/v1/catalog/uoms
  199 +curl -s -H "Authorization: Bearer $ACCESS" localhost:8080/api/v1/plugins/printing-shop/plates
  200 +```
  201 +
  202 +## Module map
  203 +
  204 +```
  205 +api/api-v1 PUBLIC CONTRACT — semver-governed
  206 +platform/platform-bootstrap Spring Boot main, props, web filters
  207 +platform/platform-persistence Audit base, JPA entities, PrincipalContext
  208 +platform/platform-security JWT issuer/verifier, Spring Security config, password encoder
  209 +platform/platform-events EventBus impl, transactional outbox, poller
  210 +platform/platform-metadata MetadataLoader, MetadataController
  211 +platform/platform-plugins PF4J host, linter, Liquibase runner, endpoint dispatcher, PluginJdbc
  212 +
  213 +pbc/pbc-identity User entity end-to-end + auth + bootstrap admin
  214 +pbc/pbc-catalog Item + Uom entities + cross-PBC CatalogApi facade
  215 +
  216 +reference-customer/plugin-printing-shop
  217 + Reference plug-in: own DB schema (plate, ink_recipe),
  218 + own REST endpoints, own metadata YAML
  219 +
  220 +distribution Bootable Spring Boot fat-jar assembly
  221 +```
  222 +
  223 +11 Gradle subprojects. Architectural dependency rule (PBCs never import each other; plug-ins only see api.v1) is enforced by the root `build.gradle.kts` at configuration time.
  224 +
  225 +## Where to look next
  226 +
  227 +- **Detailed roadmap:** [`docs/superpowers/specs/2026-04-07-vibe-erp-implementation-plan.md`](docs/superpowers/specs/2026-04-07-vibe-erp-implementation-plan.md) — every unit, every dependency, every acceptance test.
  228 +- **Architecture rationale:** [`docs/superpowers/specs/2026-04-07-vibe-erp-architecture-design.md`](docs/superpowers/specs/2026-04-07-vibe-erp-architecture-design.md) — 14 sections, validated against 2026 ERP/EBC SOTA.
  229 +- **Project guardrails:** [`CLAUDE.md`](CLAUDE.md) — the 11 rules every change is held to.
  230 +- **Git history:** every chunk is one commit with a detailed message describing what landed, what was deferred, and any bug caught by the smoke test.
README.md
  View file @95b26a8
@@ -76,22 +76,34 @@ vibe-erp/ @@ -76,22 +76,34 @@ vibe-erp/
76 76
77 ## Building 77 ## Building
78 78
79 -This is a v0.1 skeleton. Not all modules ship yet — expect commands below to work for the modules that exist and to be no-ops or stubs for the rest.  
80 -  
81 ```bash 79 ```bash
82 -# Build everything that currently exists 80 +# Build everything (compiles 11 modules, runs 92 unit tests)
83 ./gradlew build 81 ./gradlew build
84 82
85 -# Run the bootable distribution against a local Postgres  
86 -./gradlew :distribution:bootRun 83 +# Bring up Postgres + the reference plug-in JAR
  84 +docker compose up -d db
  85 +./gradlew :reference-customer:plugin-printing-shop:installToDev
87 86
88 -# Or bring everything (Postgres + vibe_erp) up with Docker  
89 -docker compose up 87 +# Boot the framework against it
  88 +./gradlew :distribution:bootRun
90 ``` 89 ```
91 90
  91 +The bootstrap admin password is printed to the application logs on first boot. After login, REST endpoints are live under `/api/v1/identity/users`, `/api/v1/catalog/uoms`, `/api/v1/catalog/items`, `/api/v1/plugins/printing-shop/*`, and the public introspection endpoint at `/api/v1/_meta/metadata`.
  92 +
92 ## Status 93 ## Status
93 94
94 -**v0.1** — buildable skeleton, one PBC implemented end-to-end (`pbc-identity`), plug-in loading proven with a hello-world reference plug-in. Not production. See [`docs/superpowers/specs/2026-04-07-vibe-erp-architecture-design.md`](docs/superpowers/specs/2026-04-07-vibe-erp-architecture-design.md) for the full v1.0 plan. 95 +**Current stage: foundation complete; first business surface in place.** All seven cross-cutting platform services are live and verified end-to-end against a real Postgres: auth (JWT + Argon2id + bootstrap admin), plug-in HTTP endpoints, plug-in linter (ASM bytecode scan), plug-in-owned DB schemas + typed SQL, event bus + transactional outbox, and the metadata seeder. Two real PBCs (identity + catalog) validate the modular-monolith template. The reference printing-shop plug-in has graduated from "hello world" to a real customer demonstration: it owns its own DB schema, CRUDs its own domain via REST, and would be rejected at install time if it tried to import any internal framework class.
  96 +
  97 +| | |
  98 +|---|---|
  99 +| Modules | 11 |
  100 +| Unit tests | 92, all green |
  101 +| Real PBCs | 2 of 10 |
  102 +| Cross-cutting services live | 7 |
  103 +| Plug-ins serving HTTP | 1 (reference printing-shop) |
  104 +| Production-ready | **No** — workflow engine, forms, web SPA, more PBCs all still pending |
  105 +
  106 +For the full feature inventory, completed work, and next-priority list, see [`PROGRESS.md`](PROGRESS.md). For the detailed roadmap, see [`docs/superpowers/specs/2026-04-07-vibe-erp-implementation-plan.md`](docs/superpowers/specs/2026-04-07-vibe-erp-implementation-plan.md).
95 107
96 ## Documentation 108 ## Documentation
97 109
docs/customer-onboarding/guide.md
  View file @95b26a8
@@ -6,9 +6,9 @@ For the architectural background, see [`../architecture/overview.md`](../archite @@ -6,9 +6,9 @@ For the architectural background, see [`../architecture/overview.md`](../archite
6 6
7 ## Honest scope note 7 ## Honest scope note
8 8
9 -vibe_erp is a framework, not a turnkey product. **The Tier 1 customization UIs (custom field designer, form designer, BPMN designer, list view editor, role editor) are v1.0 deliverables.** v0.1 ships only the underlying API surface — the metadata tables, the REST endpoints, the seed data — without the polished UIs on top of them. Until v1.0 ships, the steps below that say "use the Customize UI" mean "POST to the metadata REST endpoints" or "edit a YAML seed file in your plug-in JAR". 9 +vibe_erp is a framework, not a turnkey product. **The Tier 1 customization UIs (custom field designer, form designer, BPMN designer, list view editor, role editor) are v1.0 deliverables.** The current build ships only the underlying API surface — the metadata tables, the REST endpoints, the seed data — without the polished UIs on top of them. Until v1.0 ships, the steps below that say "use the Customize UI" mean "POST to the metadata REST endpoints" or "edit a YAML seed file in your plug-in JAR". See [`PROGRESS.md`](../../PROGRESS.md) for the current per-feature status.
10 10
11 -This guide is written against the v1.0 experience. Where v0.1 deviates, the step is annotated **(v0.1: API only)**. 11 +This guide is written against the v1.0 experience. Where the current build deviates, the step is annotated **(current: API only)**.
12 12
13 ## 1. Install the host 13 ## 1. Install the host
14 14
@@ -63,7 +63,7 @@ Tenant onboarding is an `INSERT` plus seed metadata, not a migration — sub-sec @@ -63,7 +63,7 @@ Tenant onboarding is an `INSERT` plus seed metadata, not a migration — sub-sec
63 63
64 ## 4. Use the Customize UI to model the customer's reality 64 ## 4. Use the Customize UI to model the customer's reality
65 65
66 -This is where most of the integrator's time is spent. Everything here is **Tier 1**: rows in `metadata__*` tables, tagged `source = 'user'`, scoped to the tenant. No build, no restart, no deploy. **(v0.1: API only — POST to the metadata endpoints; the UIs ship in v1.0.)** 66 +This is where most of the integrator's time is spent. Everything here is **Tier 1**: rows in `metadata__*` tables, tagged `source = 'user'`, scoped to the tenant. No build, no restart, no deploy. **(current: API only — POST to the metadata endpoints; the UIs ship in v1.0.)**
67 67
68 ### Custom fields 68 ### Custom fields
69 69
@@ -90,7 +90,7 @@ Draw the customer&#39;s process flow in the BPMN designer. Workflows are stored in ` @@ -90,7 +90,7 @@ Draw the customer&#39;s process flow in the BPMN designer. Workflows are stored in `
90 90
91 vibe_erp accepts master data through two paths: 91 vibe_erp accepts master data through two paths:
92 92
93 -- **CSV import** through the Customize UI for one-off bulk loads (catalog items, partners, opening stock, chart of accounts). **(v0.1: API only.)** 93 +- **CSV import** through the Customize UI for one-off bulk loads (catalog items, partners, opening stock, chart of accounts). **(current: API only.)**
94 - **REST API** for ongoing integration with the customer's existing systems. Every entity, including custom fields, is exposed through OpenAPI-documented REST endpoints. The OpenAPI spec auto-updates as you add custom fields and custom entities, so the integration code is never out of date. 94 - **REST API** for ongoing integration with the customer's existing systems. Every entity, including custom fields, is exposed through OpenAPI-documented REST endpoints. The OpenAPI spec auto-updates as you add custom fields and custom entities, so the integration code is never out of date.
95 95
96 ## 6. Configure roles and permissions 96 ## 6. Configure roles and permissions
docs/form-authoring/guide.md
  View file @95b26a8
@@ -65,7 +65,7 @@ This path is the right one for: @@ -65,7 +65,7 @@ This path is the right one for:
65 65
66 The form designer is a **v1.0 deliverable**. 66 The form designer is a **v1.0 deliverable**.
67 67
68 -### Tier 2 — JSON files in a plug-in JAR (v0.1) 68 +### Tier 2 — JSON files in a plug-in JAR
69 69
70 Plug-in authors ship form definitions inside their JAR under `src/main/resources/metadata/forms/`. The plug-in lifecycle upserts them into `metadata__form` on plug-in install, tagged `source = 'plugin:<id>'`. 70 Plug-in authors ship form definitions inside their JAR under `src/main/resources/metadata/forms/`. The plug-in lifecycle upserts them into `metadata__form` on plug-in install, tagged `source = 'plugin:<id>'`.
71 71
docs/workflow-authoring/guide.md
  View file @95b26a8
@@ -24,9 +24,9 @@ This path is the right one for: @@ -24,9 +24,9 @@ This path is the right one for:
24 - Document routing rules that the customer wants to tune themselves. 24 - Document routing rules that the customer wants to tune themselves.
25 - Workflows that compose existing typed task handlers in a new order. 25 - Workflows that compose existing typed task handlers in a new order.
26 26
27 -The visual designer is a **v1.0 deliverable**; v0.1 ships the underlying API only. 27 +The visual designer is a **v1.0 deliverable**; the current build ships the underlying API only. (Even Flowable itself is not yet wired — see [`PROGRESS.md`](../../PROGRESS.md) for the status of P2.1.)
28 28
29 -### Tier 2 — `.bpmn` files in a plug-in JAR (v0.1) 29 +### Tier 2 — `.bpmn` files in a plug-in JAR
30 30
31 Plug-in authors ship `.bpmn` files inside their JAR under `src/main/resources/workflow/`. The plug-in lifecycle deploys them to Flowable on plug-in install. The `plugin.yml` manifest lists them so the loader picks them up. 31 Plug-in authors ship `.bpmn` files inside their JAR under `src/main/resources/workflow/`. The plug-in lifecycle deploys them to Flowable on plug-in install. The `plugin.yml` manifest lists them so the loader picks them up.
32 32