docs(progress): P3.5 rules engine + P2.3 user-task forms done, bump to v0.34.0-SNAPSHOT

407 tests, all green. Rules engine with 24 unit tests for condition evaluation. User-task form rendering via MetadataFormRenderer.

docs(progress): P3.5 rules engine + P2.3 user-task forms done, bump to v0.34.0-SNAPSHOT
407 tests, all green. Rules engine with 24 unit tests for condition evaluation. User-task form rendering via MetadataFormRenderer.
zichun
1 parent 2799cc9b
Showing 3 changed files with 7 additions and 7 deletions
CLAUDE.md
PROGRESS.md
gradle.properties
@@ -96,7 +96,7 @@ plugins (incl. ref)   depend on:  api/api-v1 only
 **Foundation complete; all platform services and core PBCs live.** As of the latest commit:
  
 - **25 Gradle subprojects** built and tested (1 API + 11 platform + 10 PBC + 1 reference plug-in + web + distribution). 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`.
-- **382 unit tests across 25 modules**, all green. `./gradlew build` is the canonical full build.
+- **407 unit tests across 25 modules**, all green. `./gradlew build` is the canonical full build.
 - **All 12 cross-cutting platform services live and smoke-tested end-to-end** against real Postgres: auth (P4.1), OIDC federation (P4.2), authorization with `@RequirePermission` + JWT roles claim + AOP enforcement (P4.3), 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 + custom-field validation (P1.5 + P3.4), ICU4J translator with per-plug-in locale chain (P1.6), JasperReports renderer (P1.8), file store with local + S3 backends (P1.9), Quartz job scheduler (P1.10), plus the audit/principal context bridge.
 - **10 of 10 core PBCs implemented** (6 feature-complete, 4 at minimal v1 scope): `pbc-identity`, `pbc-catalog`, `pbc-partners`, `pbc-inventory`, `pbc-warehousing`, `pbc-orders-sales`, `pbc-orders-purchase`, `pbc-finance`, `pbc-production`, `pbc-quality`. **The full buy-sell-make loop works**: a purchase order receives stock via `PURCHASE_RECEIPT`, a sales order ships stock via `SALES_SHIPMENT`, and a work order with a bill of materials consumes raw materials via `MATERIAL_ISSUE` and produces finished goods via `PRODUCTION_RECEIPT`, all atomically in one transaction. All four write paths feed the same `inventory__stock_movement` ledger via the same `InventoryApi.recordMovement` facade.
 - **pbc-production v3** adds an IN_PROGRESS state between DRAFT and COMPLETED, a `WorkOrderInput` child entity carrying per-unit BOM consumption rates, a scrap verb, and `WorkOrderOperation` child entity with per-op sequential state machine and operator-entered actual minutes for variance reporting. Shop-floor dashboard projects IN_PROGRESS work orders with progress bars.
@@ -10,11 +10,11 @@
  
 | | |
 |---|---|
-| **Latest version**             | v0.33.0-SNAPSHOT (P3.2 form renderer + P3.3 form designer + P3.6 list view designer + R3 metadata admin) |
-| **Latest commit**              | `558467e feat(web): list view designer` |
+| **Latest version**             | v0.34.0-SNAPSHOT (P3.5 rules engine + P2.3 user-task forms + P3.2/P3.3/P3.6/R3 metadata UIs) |
+| **Latest commit**              | `2799cc9 feat(web): user-task pages + rules tab` |
 | **Repo**                       | https://github.com/reporkey/vibe-erp |
 | **Modules**                    | 25 JVM subprojects + `:web` SPA |
-| **Unit tests**                 | 382, all green |
+| **Unit tests**                 | 407, all green |
 | **Real PBCs implemented**      | **10 of 10** (pbc-identity, pbc-catalog, pbc-partners, pbc-inventory, pbc-warehousing, pbc-orders-sales, pbc-orders-purchase, pbc-finance, pbc-production, pbc-quality) — P5.x row of the implementation plan complete at minimal v1 scope |
 | **End-to-end smoke runs**      | An SO confirmed with 2 lines auto-spawns 2 draft work orders via `SalesOrderConfirmedSubscriber`; completing one credits the finished-good stock via `PRODUCTION_RECEIPT`, cancelling the other flips its status, and a manual WO can still be created with no source SO. All in one run: 6 outbox rows DISPATCHED across `orders_sales.SalesOrder` and `production.WorkOrder` topics; pbc-finance still writes its AR row for the underlying SO; the `inventory__stock_movement` ledger carries the production receipt tagged `WO:<code>`. First PBC that REACTS to another PBC's events by creating new business state (not just derived reporting state). |
 | **Plug-ins serving HTTP**      | 1 (reference printing-shop, 7 endpoints + own DB schema + own metadata + own i18n bundles) |
@@ -53,7 +53,7 @@ That target breaks down into roughly 30 work units across 8 phases. About **22 a
 |---|---|---|
 | P2.1 | Embedded Flowable (BPMN 2.0) + `TaskHandler` wiring | ✅ DONE — `7bff422` core + `ef9e5b4` principal propagation + `a091d38` plug-in-loaded handler registration + `66ad87d` plug-in JAR BPMN auto-deployment — `platform-workflow` module shares host Postgres; dispatcher routes service-task execution to `TaskHandlerRegistry` beans by activity id; authenticated HTTP caller's principal flows through reserved `__vibeerp_*` process vars into `ctx.principal()`; plug-ins register handlers via `context.taskHandlers` + ship BPMNs under `processes/*.bpmn20.xml` in their JAR (host `PluginProcessDeployer` reads + deploys with `category=pluginId` + cascading undeploy on stop); `POST/GET /api/v1/workflow/**` endpoints; reference plug-in ships a live `plugin-printing-shop-plate-approval` BPMN driving `printing_shop.plate.approve` |
 | P2.2 | BPMN designer (web) | 🔜 Pending — depends on R1 |
-| P2.3 | User-task form rendering | 🔜 Pending |
+| P2.3 | User-task form rendering | ✅ DONE — `2799cc9` — UserTasksPage lists pending Flowable user-tasks; TaskDetailPage renders forms via MetadataFormRenderer when formKey starts with `vibe:`. Task completion POST sends form data as process variables. WorkflowController extended with list/detail/complete endpoints. |
  
 ### Phase 3 — Metadata store: forms and rules (Tier 1 customization)
  
@@ -63,7 +63,7 @@ That target breaks down into roughly 30 work units across 8 phases. About **22 a
 | P3.2 | Form renderer (web) | ✅ DONE — `1875c06` — `MetadataFormRenderer` component using @rjsf/core with custom VibeErp Tailwind theme + 6 ERP widgets (partner-picker, item-picker, uom-selector, location-picker, money-input, quantity-input). Renders forms from `metadata__form` definitions. Supports visibility conditions via `ui:visible` in uiSchema. |
 | P3.3 | Form designer (web) | ✅ DONE — `558467e` — Structured property editor with live @rjsf preview. Left panel: field list with inline property panels (label, placeholder, help text, widget override, visibility condition). Right panel: real-time preview. Generates JSON Schema + UI Schema from field definitions. Edit mode hydrates from existing definitions. |
 | P3.4 | Custom field application (JSONB `ext` validation) | ✅ DONE — `5bffbc4` |
-| P3.5 | Rules engine (event-driven) | 🔜 Pending |
+| P3.5 | Rules engine (event-driven) | ✅ DONE — `2799cc9` — Event-condition-action rules stored as `metadata__rule` rows. RuleEngine subscribes to event bus by topic, evaluates conditions (8 operators, AND/OR logic) against event properties, executes actions (v1.0: log with template substitution). RuleEvaluator has 24 unit tests. Rules tab in MetadataAdmin with inline create/edit/delete form. |
 | P3.6 | List view designer (web) | ✅ DONE — `558467e` — Column/filter/sort configuration editor with live DataTable preview. Columns: show/hide, label, format, sortable, reorder. Filters: field, operator, label. Default sort + page size. Edit mode loads existing definitions. |
  
 ### Phase 4 — Authentication and authorization
@@ -19,6 +19,6 @@ kotlin.incremental=true
 #     api/api-v1/build.gradle.kts.
 # Bump this line in lockstep with PROGRESS.md's "Latest version"
 # row when shipping a new working surface.
-vibeerp.version=0.33.0-SNAPSHOT
+vibeerp.version=0.34.0-SNAPSHOT
 vibeerp.api.version=1.0.0-SNAPSHOT
 vibeerp.group=org.vibeerp