Prompt — Master Design Rev2 MP-D11..MP-D15: Bidirectional Input, Kaizen, Unified MOW UI, MOT/JFT, Governance at Scale

Date: 2026-05-28 Author: GPT Council via Web Connector fallback Target agent: Claude Code / Architecture Agent Mode: DOCUMENT ONLY Production mutation: FORBIDDEN Applies after: Master Design Rev2 Revision 2

0. Mission

Patch the existing IU-Centered 4 Mothers + Event Foundation — Master Design Rev2 with a focused document-only addendum covering a missing but critical set of requirements/design details:

• Bidirectional data flow and staging input architecture.
• Unified MOW hierarchy UI from T6 to T1.
• Kaizen proposal intake: easiest possible contribution by employees.
• MOT/JFT task envelope as matrix/config assembly.
• Governance UI for super-admin and AI/Agent operations at very large scale.

This is NOT a rewrite. This is a design patch/addendum to ensure the infrastructure can support the real long-term operational vision.

1. Read first

Read directly before editing:

1. knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/00-master-design-rev2.md latest revision.
2. knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/02-step-state-machine-and-workflow-ui-design.md latest revision.
3. knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/03-event-5layer-realtime-dlq-design.md latest revision.
4. knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/04-iu-centered-4mothers-binding-design.md latest revision.
5. knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/06-open-decisions-and-readiness.md latest revision.
6. knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/07-master-design-rev2-report.md latest revision.
7. knowledge/dev/reports/architecture/iu-4mothers-event-master-design-rev2-r2-gpt-final-review-2026-05-27.md.
8. Rev2 requirement brief and patch report if needed.
9. Relevant Drive/upload-derived content already consolidated in KB: 4 mẹ mở rộng, Bắt sự kiện của PG, MOW/MOT/JFT notes.
10. Laws: Hiến pháp, Điều 7 Assembly First, Điều 28 Nuxt render shell, Điều 32 approval, Điều 33 PG/Directus/Nuxt boundary, Điều 37 governance organization, Điều 39 IU/KG, Điều 45 event/queue/executor/heartbeat.

If raw Drive files are not directly accessible, use the existing consolidated KB reports and state the access condition. Do not pretend to read inaccessible files.

2. Strategic clarification to encode

2.1 Kaizen is simple intake, not user-side process editing

Do NOT design Kaizen as if ordinary users edit workflow logic.

The goal is much simpler and much more important:

• Capture the problem.
• Locate the exact place of the problem.
• Capture minimal user text/audio at the exact node/edge/task context.
• Automatically capture all surrounding context so the user does not need to explain.
• Route the suggestion to a governance/review process.

User flow:

1. User clicks Đề xuất cải tiến.
2. User chooses one of three simple intents:
   • thêm / add;
   • sửa / edit;
   • xoá / delete.
3. User clicks the target node, edge, task, step, or insertion position.
4. User enters a short text comment OR records an audio comment.
5. System captures context automatically and submits to staging/proposal.

User is NOT expected to understand workflow design, graph theory, BPMN, schema, registry, or queue/event mechanics.

2.2 Input flow canonicalization

The basic input flow is:

Nuxt → Temporary/Staging Collection → Processing → PG Canonical

The processing step has two branches:

1. processing = no-op/direct canonicalization

   • Input is valid, low-risk, permission-clear, and can be inserted/promoted to PG canonical quickly.
   • Example: human is already entering the authoritative data; entering directly is the highest-cost/highest-confidence data source. If later wrong, correct by audit/versioned correction.

2. processing = workflow/queue/event review path

   • Input needs validation, enrichment, approval, AI review, worker processing, multi-step workflow, or governance before canonical PG write.

Both branches start from staging; staging is not final SoT.

2.3 Unified UI visibility is permission-filtered

There is one consistent UI pattern, but different roles see radically different slices.

• Staff may see only 10–20 assigned tasks and their own department/process area.
• Department lead may see their department/processes.
• Super admin may need to govern thousands or 20,000+ tasks/problems/events.

Therefore the MOW/MOT/Governance UI design must distinguish:

• operator/task dashboard — small personal work list, JFT.
• process canvas — T6→T1 hierarchy view.
• super-admin governance cockpit — aggregated, problem-first, large-scale, drill-down only on demand.

Do not assume the process canvas is suitable for 20k task supervision. At scale, governance requires professional IT operations patterns: aggregates, filters, facets, SLOs, queues, triage, severity, ownership, drill-down, not a giant canvas.

3. Patch set to apply

MP-D11 — Bidirectional Data Flow + Staging Input Architecture

Add explicit bidirectional information architecture:

Read/display path:

PG → Directus → Nuxt

Input path:

Nuxt → Directus/Staging Collection → Processing → PG

Processing split:

• direct/no-op canonicalization to PG;
• processing workflow/event/queue/review path before PG.

Design requirements:

• Nuxt is render/input shell only.
• Nuxt never writes PG directly.
• Nuxt does not contain business validation logic.
• Directus/Staging Collection is intake/staging/admin/API surface, not final SoT.
• PG canonical registry/table is SoT after canonicalization.
• Every staging record has at least:
  • staging_id;
  • input_kind;
  • source_actor_id;
  • source_role;
  • source_surface;
  • hierarchy_context;
  • target_artifact_ref;
  • intent;
  • raw_text nullable;
  • audio_ref nullable;
  • attachments_ref nullable;
  • captured_context_jsonb;
  • validation_status;
  • processing_state;
  • processing_branch = direct | workflow;
  • canonical_target_ref nullable;
  • rejection_reason nullable;
  • trace_id;
  • correlation_id;
  • created_at.
• Event/queue carries refs only.
• Canonicalization emits events and audit.

MP-D12 — Unified MOW Hierarchy Canvas T6→T1

Add a MOW UI design section describing one consistent canvas pattern across hierarchy levels:

• T6 Lĩnh vực.
• T5 Công ty.
• T4 Phòng ban.
• T3 Chuyên môn.
• T2 Nhiệm vụ / Workflow.
• T1 Task.
• T0 Field exists as atomic schema layer but is not counted as an official hierarchy tier.

Design concept:

• Top tabs: T6→T1.
• Breadcrumb shows current path.
• The selected tier determines what each main node/card represents.
• Child rows under each card show the next lower tier.
• Same UI pattern must work for each tier.
• Active tab determines current modeling layer.
• Node cards are IU-backed or bundle-backed where appropriate.
• The canvas is for understanding process structure and localized proposal intake; it is not the super-admin 20k task governance view.

Example semantics:

• At T3 Chuyên môn: each card = one chuyên môn; child rows = nhiệm vụ/workflows under that chuyên môn.
• At T2 Nhiệm vụ: each card = one workflow step/mission; child rows = tasks.
• At T1 Task: card/list = task envelopes and execution state.

MP-D13 — Inline Kaizen Proposal Intake

Add a Kaizen design section focused on minimal user effort.

User can:

• click Đề xuất cải tiến;
• choose one of exactly 3 simple intents: add / edit / delete;
• click target node/edge/position;
• add short text or audio;
• submit.

System captures automatically:

• current hierarchy level T6..T1;
• breadcrumb path;
• target node id;
• target parent id;
• insertion position / before / after / inside;
• current IU/bundle refs;
• workflow_def_id / workflow_run_id if applicable;
• task_run_id / step_run_id if applicable;
• actor id / role / department;
• permission scope;
• timestamp;
• trace_id / correlation_id;
• screen context / filters;
• selected intent.

Kaizen output routes:

• workflow-level graph proposal → workflow_change_requests.
• non-workflow proposal → generic proposal.
• raw intake artifact → staging input collection.
• audio → file metadata/staging, with transcription as processing task later.

Important:

• User suggestion never mutates canonical workflow/IU/registry directly.
• User does not need to understand the system.
• The review team later interprets, normalizes, merges, rejects, or converts into formal proposals.
• This supports continuous improvement culture and captures ideas from people closest to the work.

MP-D14 — MOT/JFT Task Envelope Matrix

Add a stronger MOT design section:

MOT is a fixed task frame assembled from config/matrix:

• Header: task metadata, state, deadline, assignee, trace.
• Input area: MOIT field groups/form contract.
• Reference area: MOUT reference/output/context.
• Instruction area: IU or IU bundle render.
• Action area: submit, save, cannot_complete, comment, attach evidence.
• State/deadline/escalation area: traffic-light, waiting facet, escalation.

Task is generated from a matrix/config row that binds:

• task_template_id;
• IU/bundle instruction;
• MOIT input contract;
• MOUT reference/output contract;
• trigger_subscription;
• assignee/PIC policy;
• deadline/SLA policy;
• executor_class_ref;
• state_machine_id;
• dashboard_target.

JFT semantics:

• right task;
• right person/agent;
• right time;
• pushed to dashboard only when ready or actionable;
• disappears/archives when done unless follow-up needed;
• deadline and escalation automatic.

This is the foundation for generating tens of thousands of workflows/tasks from tables/matrices + DOT/config. Design must list all required inputs before auto-generation is safe.

MP-D15 — Governance at Scale for Super Admin + AI/Agent Operations

Extend governance design beyond staff dashboard and canvas.

Problem:

• Staff sees 10–20 tasks.
• Super admin may need to supervise thousands to 20,000+ tasks/events/problems.
• Canvas UI cannot be the primary super-admin governance UI at that scale.

Design a professional governance cockpit:

• aggregate-first;
• problem-first;
• severity-based;
• SLO/SLA metrics;
• queues by owner/domain/department/severity;
• filters/facets/search;
• heatmaps by hierarchy level;
• trend lines;
• event lag p50/p95/p99;
• DLQ counts;
• silent worker/heartbeat;
• overdue/blocked/cannot_complete clusters;
• Kaizen suggestion volume and quality metrics;
• AI/Agent status with evidence-backed summaries;
• drill-down to trace_id/correlation_id/task/workflow/IU.

Separate UI surfaces:

1. Personal JFT Dashboard — what I need to do now.
2. MOW Hierarchy Canvas — understand and propose improvements at the right location.
3. Governance Cockpit — operate the company-scale system.
4. AI/Agent Ops Console — monitor workers/agents, prompts, task queues, heartbeat, failure clusters.

Governance UI must not show raw event noise by default. It shows problems, summaries, trends and drill-down.

Consider assembly-first/open-source options only as future adapter slots, not final picks. Candidate examples may include lightweight observability/dashboard tools or tracing tools, but design must preserve PG as SoT and Directus/Nuxt boundaries. No final OSS tool selection.

4. Files to patch

Patch or add addendum under:

knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/

Minimum required updates:

1. 00-master-design-rev2.md

   • add top-level invariant for bidirectional data flow and staging input;
   • add note that MOW canvas is not super-admin 20k task governance UI.

2. 02-step-state-machine-and-workflow-ui-design.md

   • add Unified MOW Hierarchy Canvas T6→T1;
   • add Kaizen inline proposal mode;
   • add governance cockpit at scale distinction.

3. 03-event-5layer-realtime-dlq-design.md

   • add input submission event flow;
   • add audio/text proposal event contract;
   • add canonicalization events;
   • preserve refs-only payload.

4. 04-iu-centered-4mothers-binding-design.md

   • add MOIT staging input architecture;
   • add MOT/JFT task envelope matrix;
   • add input minimalism/context maximization.

5. 06-open-decisions-and-readiness.md

   • add readiness items for staging collection/input_submission/proposal intake/transcription processing/governance cockpit;
   • add any open decision if needed.

6. 07-master-design-rev2-report.md

   • add patch log MP-D11..MP-D15 and update next steps.

Optional if cleaner:

• Create new file 08-bidirectional-input-kaizen-governance-addendum.md and cross-link from the above files. If creating new file, still update 00 and 07 so reviewers find it.

5. Acceptance criteria

PASS only if:

• Bidirectional flow is explicit: PG→Directus→Nuxt and Nuxt→Staging→Processing→PG.
• Processing branch supports both direct canonicalization and workflow/queue review path.
• Kaizen is simple intake, not user-side process editing.
• User can submit add/edit/delete suggestion with text or audio at exact location.
• System auto-captures context sufficient for review without extra user burden.
• Unified MOW Hierarchy Canvas T6→T1 is documented.
• Personal JFT dashboard, MOW canvas, super-admin governance cockpit, and AI/Agent ops console are distinguished.
• MOT/JFT task envelope matrix is explicit enough to support generation of many tasks/workflows from config/matrix.
• Permission-filtered visibility is explicit; staff sees their slice, super admin sees aggregate/cockpit.
• Governance at scale is designed using problem-first, aggregate-first, severity/SLO/drill-down patterns.
• Nuxt remains render/input shell only.
• Directus/Staging remains API/admin/staging layer, not workflow engine and not final SoT.
• PG remains canonical SoT.
• No implementation or final OSS selection.

PARTIAL only with exact unapplied gap.

6. Forbidden

• No PG mutation.
• No Directus mutation.
• No Qdrant/vector write.
• No migration.
• No DOT command run.
• No law enactment.
• No implementation.
• No UI deployment.
• No final OSS tool selection.
• No direct raw SQL apply.

7. Final report must include

• patched file paths + revisions;
• MP-D11..MP-D15 status table;
• what was added;
• law/boundary compliance statement;
• how this affects next macro sequencing;
• any remaining open decisions;
• forbidden compliance statement.

End prompt.