朱子纯 / erp-framework-wiki

User asked: are there examples of customising workflow other than
the standard hardcoded one? Investigated and found a substantial
customer example.

Findings:
- script/客户/万昌/计件工资/日报审核/领班驳回.sql is a 185-line
  customer-side workflow customisation defining
  Sp_mftproductionreportmaster_check1_0 ("Foreman Rejection",
  state 1 → state 0 transition).
- Naming convention: Sp_<table>_check<currentState>_<nextState>.
  No procs in standard DB use this pattern; it's 万昌's own
  convention.
- The proc resets SIX approval flags simultaneously (bManager,
  bIPQC, bDeputy, bSubmit, bWorkshopManager, bCheck) — 万昌 has
  ALTER TABLEd mftproductionreportmaster to add 5 columns that
  don't exist in the standard schema.
- Adds sRejectMemo rejection-reason history (also custom column),
  appends each rejection's reason + timestamp + foreman name.
- Calls sp_add_flow_log — a custom audit-log proc that doesn't
  exist in the standard DB.
- Includes customer-specific business rules (e.g., block rejection
  if any slave row has bSAPCheck=1 — SAP-sync guard).

So the answer to "any examples of customising workflow":
- Yes — 万昌 has built their OWN multi-level approval workflow on
  top of xly's button-dispatch primitive: schema extension +
  custom transition procs + custom audit log. The framework
  provides only the button-press dispatch (via /business/
  genericProcedureCall* or sButtonParam); everything else is
  customer-defined.
- This is fundamentally different from Activiti — no BPMN, no FSM
  library, no engine. Just SQL + ALTER TABLE.
- Other customer dirs (千彩, 重庆展印, 朝阳, etc.) mostly customise
  *calculations and reports*, not workflow. 万昌's pattern is
  rare but real.

Slice 5 gets a "Worked-example 2" section walking through
领班驳回.sql in detail, plus a customisation-patterns-at-a-glance
breakdown of what each of the 18 customer dirs actually contains.

Activiti.md gets a back-reference: "A real Path-1 customisation
example" pointing at the new slice 5 worked example, with the
empirical observation that Activiti deployment is NOT seen in any
script/客户/ directory.

Third commit closing high-value gaps the user flagged in the
verification plan.

Cross-node cache coherence — LOCKED EMPIRICALLY:
- Connected to live Redis at 118.178.19.35:16379 db=0.
- 233 of 267 keys use Spring's `<cacheName>::<key>` separator.
- Confirmed key shapes match @Cacheable SpEL specs:
    businessGdsconfigformsServiceGetFormconstData::{...}  (37 entries)
    gdsmoduleById::gdsmoduleById_<sBrandsId>_<sSubsidiaryId>_<sLanguage>  (2 entries)
- Conclusion: Spring's RedisCacheManager IS the active CacheManager.
  @CacheEvict on any node clears the shared Redis store; cross-node
  coherence works without any JMS involvement. Removed the "open
  question" hedge in cache-invalidation.md.

New page — Metadata-management services (xlyManage):
- Closes the biggest documentation gap surfaced by Pass C2.
- Catalogs the 8 large Gds*ServiceImpl classes (878+729+555+489+
  362+319+243+221 = ~3,800 lines of metadata-CRUD logic) plus
  CommonServiceImpl (56) and SysbrandsServiceImpl (125).
- Documents the universal five-method shape every Gds*Service
  follows (get/getBysId/add/update/delete) and how it pairs with
  the corresponding Gds*Controller in xlyEntry/.../systemweb/.
- Maps each service to its BACK admin screen.
- Notes the cache-invalidation hookpoint (synchronous
  BusinessCleanRedisData.delCleanRedisData* on commit).
- Added to mkdocs nav under Reference (Maintainer).

Worked examples:
- Slice 04: gdsconfigformcustomslave is empty in the dev DB
  (0 rows). Updated the open verification item to confirm this
  rather than leave the framing "depends on the deployment".
- Slice 05: side-by-side diff of 重庆展印's Sp_SalSalesCheck vs
  the standard. Quantified differences (1714 vs 723 lines, same
  14-param signature, override adds CbxSrcNoCheck branch and
  strips temp-table aggregation, 12 sibling procs use the same
  CbxSrcNoCheck pattern). Added a copy-pasteable diff command.

Honest scope acknowledgement:
- api-reference/internal.md: explicit "what this catalog
  includes vs treats as illustrative" paragraph. ~19 framework-
  primitive controllers documented; ~52 business-domain
  controllers (workorder/salesorder/productionPlan/etc.) treated
  as illustrations of the framework at work, with grep guidance
  for maintainers who need to find them.

Auto-catalog regenerated:
- Ran scripts/gen_catalog.py against live DB. No changes
  (catalog was already current); 3081 generated pages.

Pass E save trace:
- Tried multiple angles (UI flow, hand-crafted POST with token
  in Authorization header, fetch interception). Edit-mode UI
  didn't yield a save fire under our setup (Ant Design grid +
  Vue SPA edit-mode peculiarity). Read trace remains
  fully verified end-to-end. Save body shape is documented in
  the Javadoc on BusinessBaseController.java:161-163 and
  reflected in the wiki; live save corroboration deferred again.

Verified every factual claim in the hand-written prose against the
codebase under ../xly/ and the live xlyweberp_saas_ai schema, and fixed
the drift:

- semantic-fk: clarified — zero FKs on xly tables; the ones that exist
  are all on bundled Activiti / Quartz schemas, which the runtime
  doesn't join through.
- multi-tenancy / runtime / slice 2: corrected RequestAddParamUtil shape
  (16 keys, 56 lines), noted the parallel xlyApi copy.
- slice 1: corrected line ranges for addUpdateDelBusinessData;
  clarified that sTableNameList is a cache-invalidation gate, not an
  authorisation gate; corrected the gdsroute claim — unregistered paths
  are NOT 404'd server-side, the SPA uses gdsroute as a client-side
  whitelist (web-verified).
- runtime: fixed controller package paths
  (Gdsmodule/Gdsconfigform/Gdsconfigtb live in systemweb/, not
  businessweb/); added CheckFlowController.
- sql-templates / proc-dispatch: 8 scaffolds, not 7 (sSqlStr.sql).
- master-slave: removed table names that don't exist (accOrderCostAnalysisMaster,
  quoQuotationCalc, mftWorkOrderCalc, mftWorkOrderSlaveMoney);
  added the *_tmp family that does.
- permissions: full rewrite. The original page described
  gdsjurisdiction as a per-(module, role, button) rule table backed by
  empty plat_base_authority_* lookups; reality is gdsjurisdiction is a
  per-module catalog of buttons/actions, with sysjurisdiction carrying
  the actual role/user grants.
- Removed environment-specific facts (row counts, sizes, timestamps,
  per-DB enumerations) so the wiki documents the framework, not one
  particular DB snapshot.

Auto-catalog generator (en/scripts/gen_catalog.py):
- Rewritten to query MySQL directly via ~/.my.cnf (replaces the
  recon/*.tsv pipeline).
- Stripped ephemeral fields from output (Rows, Data size, Created,
  Updated on tables; Created, Last altered on routines; Definer on
  views).
- Strips the schema-name prefix from VIEW_DEFINITION so view bodies
  are portable across deployments.
- Wipes and rewrites docs/auto-catalog/{tables,views,procedures,functions}/
  on each run.
- Auto-catalog regenerated.

New API Reference chapter (5):
- concepts/api-surface.md introduces the three-tier design (xlyEntry
  internal, xlyApi external, xlyInterface webhooks).
- api-reference/{index,internal,external,webhooks,messaging}.md cover
  each surface, with the data-driven /api/invoke{sApiCode} pattern,
  sysapi schema, token flow, and the SpringFox Swagger UI location on
  xlyInterface.
- mkdocs nav: chapters renumbered (Auto-Catalog → 6, Glossary → 7,
  Contributing → 8); glossary/contributing wrapped as section indexes
  to render correctly under navigation.sections.

Other:
- Bilingual top-level README (Chinese + English).
- requirements.txt: pymysql added for the new generator.

Documents the xly (小羚羊) printing-industry ERP framework. Built with
MkDocs Material; CJK search via jieba; 3,076 auto-generated catalog
pages from recon/*.tsv plus hand-written prose for the framework's
core mental model and end-to-end vertical slices.

Phase 0 recon: stack, schema shape, framework metadata layer, scope.
Phase 1 wiki: scaffold + auto-catalog + Slices 1-6 (Slice 7 deferred).

Slice coverage:
  1. CRUD module (Hello World) — observed network + cited source
  2. Multi-tenancy & product editions — sBrandsId/sSubsidiaryId/sVersionFlowId
  3. View-backed module (read-only report)
  4. Custom field overlay (gdsconfigformcustomslave)
  5. Per-customer SQL override (script/客户/<customer>/)
  6. Hardware integration (xlyPlc, optional)
  7. Workflow (deferred — Activiti tables empty in dev DB)

Concepts: thesis, modules-forms-vtables, master/slave, semantic-FK,
customization channels & layers, multi-tenancy, request lifecycle.

Reference (Builder): define-form, define-vtable, permissions,
attach-workflow (deferred).

Reference (Maintainer): runtime, proc-dispatch, cache-invalidation,
sql-templates, deployment, activiti.