Prompt file imported from migoamigoea-star/ioi-docs-uploads (.github/prompts/reporttxt-source-to-canvas.prompt.md). Copyright stays with the author.

Report.txt Source-to-Canvas Form Creation Pipeline

Use this prompt when a form or department must be built as a production Canvas App from complete *_all_report.txt evidence.

Objective

Create a complete Canvas App form implementation path from source report evidence to compliant .pa.yaml screens:

1. Review complete *_all_report.txt documents.
2. Document form nature, field details, field logic, workflow, and actions.
3. Map fields to existing SharePoint schema first.
4. Emit PnP provisioning CSV only for truly missing fields.
5. Design screens based on business requirements of the form, source evidence, and the design must follow as per Canvas Screen requirements spec below;

🆕 Canvas Screen Requirement Spec: Before generating any .pa.yaml, the implementing agent MUST read design/IOI-CANVAS-SCREEN-SPEC.md — the if you are replicating image/screen shoot ot HTML from Stitch, the implementing agent MUST read design/IOI-CANVAS-SCREEN-SPEC.md and follow the spec for every screen. The spec includes:ABD THE Layout architecture (§2): Exact X/Y/Width/Height for every region.

• Typography mapping (§3): Stitch CSS px → Canvas PA Size
• Color system (§4): IOI palette + gblITTheme object
• Container strategy (§5): AutoLayout rules, LayoutMinWidth=0
• All control properties (§6): 15 controls with exact values
• Screen templates (§7, §23): Index, New, Detail, Approval, Tasks, Action Hub, Dashboard, Report, Admin
• KPI cards must be set up based on the form requirement do not create generic KPI cards (§8),add chart, Tab bar for section, tables to view list (§9), Workflow timeline (§10), attachment upload/viewer (§11), comments (§12), audit trail (§13), approval panel (§14), loading indicator (§15), Dynamic action button and other source-backed sections (§15).
• Responsive design by using container (§18), validation (§20), people picker by utilising user 365 connector (§21), HtmlViewer for all visual that ready onky, epecillag show cashinf something relate to progress, workflow,step, approval, anything that can look appealing by uusing rich HTML capabilities(§25)
• PAC CLI (§26): pack/unpack + common errors
• Compliance checklist (§16): 20-point gate per screen

Violation rule: Any screen that does not match the dimensions, typography, spacing, or naming from this spec must be corrected before handoff.

6. Generate Canvas .pa.yaml using canvas-apps-ui-gen.
7. Build Power Fx formulas using the project Power Fx instructions.
8. Audit and fix .pa.yaml until it passes.
9. Repeat screen-by-screen until the form/app is complete with no duplicates.

Design quality goal:

• Every generated screen must look professional, appealing, functional, responsive, and enterprise-ready and 100% ready for production.
• The visual quality bar is a screen that looks designed by a senior product designer for a polished Microsoft 365 / Power Apps business application.
• Do not accept generic generated mockups, crowded layouts, overlapped or hidden elements, weak hierarchy, inconsistent spacing, non-responsive compositions, or screens that look visually unfinished.

Non-negotiable UI gates:

• Every form must include attachment upload for new submission screen and attachment viewer capability for detail or approval screens unless the assessment explicitly states Attachments not required with source evidence
• Use HTML Text/HtmlViewer for read-only rich visual fidelity when native Canvas controls cannot match the Stitch design, especially workflow timelines, attachment/comment/audit panels, preview panes, KPI/chart/matrix blocks, and polished typography.

Required Sources

Primary:

• source/dxl/**/_all_report.txt
• source/dxl-reports-consolidated/**/_all_report.txt

Supporting:

• Existing SharePoint schema exports and generated models/services.
• Existing Canvas .pa.yaml screens.
• Existing TSX/Code App screens, as behavior reference only.
• XML/DXL/PDF only when needed to resolve a report gap or conflict.

*_all_report.txt is the first-stage source of truth for complete form evidence. If a form has no complete report file, mark it Blocked or Needs confirmation unless the user explicitly approves a non-report source path.

Pipeline

Stage 1: Report Evidence Review

Invoke or follow @domino-migration-agent.

Extract:

• form name, aliases, department, site/location
• business purpose and form nature
• views/list screens
• fields and Domino field types
• formulas, hide-when rules, defaults, validation, computed fields
• buttons/actions
• workflow/status clues
• agents, reminders, scheduled tasks, notifications
• related forms, child forms, and lookup/reference data

Output:

• source-evidence.md

Stage 2: Form Nature Classification

Classify each form as one or more of:

• Help Desk
• Database/Register
• Approval
• Documentation/Document Control
• Notification
• Inspection/Checklist
• Request Form
• Admin/Config
• Dashboard/Report
• Workflow Action Hub
• Hybrid

Do not assume New/List/Detail. Identify the actual screen model required by the source. ITSSR-style management, report, and action screens are valid when evidence supports them.

Output:

• form-nature-assessment.md

Stage 3: Field and Logic Documentation

Document every field:

• source field name
• display label
• Domino type
• inferred SharePoint type
• Canvas control
• required/optional
• editable/read-only/computed/system-generated
• default value
• validation formula
• hide/show logic
• dependency logic
• section
• workflow role
• notes/gaps

Document buttons/actions separately:

• source button/action name
• visibility rule
• enabled/disabled rule
• validation before action
• status transition
• notification/approval effect
• target flow or Power Fx formula

Output:

• field-logic-inventory.xlsx or .csv

Stage 4: SharePoint Mapping and Normalization

Load the target SharePoint schema before proposing new fields.

Mapping precedence:

1. Exact internal column match.
2. Defensible semantic/alias match.
3. New field proposal.

Field type rules:

• Single selection -> SharePoint Choice + dropdown/radio.
• Multi-selection -> SharePoint multi-choice + ComboBox.
• Real person/requester/approver/owner -> SharePoint Person where available plus Office365Users.
• CC -> multiple person selection.
• Email delivery -> Office365Outlook or Power Automate.
• Human approvals -> Power Automate Approvals triggered from Canvas.
• Repeating rows/tables -> child SharePoint list.
• Attachments -> required by default. Provide upload and viewer capability for every form unless source evidence proves attachments are not required. Use the existing SharePoint attachment policy, document library, or attachment child list when known; otherwise keep the attachment section and mark binding Needs confirmation.

Output:

• field-mapping-register.xlsx
• field-gaps.csv
• pnp-provision-columns.csv

Stage 5: Screen Architecture

Create a screen registry before generating any screen.

Allowed screen types include:

• Dashboard
• Search/List
• New
• Edit
• Detail
• Review
• Report
• Attachment View Archive screen types include:
• Approval Panel
• Workflow Timeline
• Admin Config
• Pop Up Screen
• Dialogue Screen
• Email Screen
• Personal Home Page Screen
• Document Library
• Management Report
• Action Hub
• Child Item Entry
• Reminder Console

Rules:

• Every required screen must be source-backed.
• Do not generate duplicate screens.
• Do not invent any fields, sections, or screens that are not present in the source evidence.
• Make sure the field type is accurate and matches the source evidence.
• Always plan the navigation and workflow between screens based on the source evidence.
• Do not create generic screens when the source describes a specialized screen.
• Make sure the field logic, workflow, and actions are accurately represented in the screen design.
• Each row must include screen name, target .pa.yaml file, purpose, source evidence, data source, attachment requirement, primary actions, and status.
• Dashboard/report/summary screens must include source-backed KPI scores, charts, and status/decision matrices where applicable.
• Detail/review/approval screens must include attachment, comments, history, and audit-trail regions when source evidence or the standard app shell requires them; otherwise mark each one Not required with evidence.

Output:

• screen-architecture.md

• screen-registry.csv

Style: Modern Microsoft 365 Fluent UI, light theme, clean enterprise layout, compact spacing, subtle borders, rounded 8px containers. Use focused, professional, governed, efficient enterprise operations styling.

Layout: Top header, collapsible left sidebar, main content area, optional right panel.

Required content: [Exact fields, table columns, workflow steps, KPI cards, charts, matrices, attachment areas, comments, audit trail, or controls]

Important: Do not create a marketing landing page. Make it look like a real operational enterprise Power Apps screen. Use SharePoint-style forms, tables, status badges, people picker, date picker, attachment upload, comments, and approval timeline where relevant.

Recommended refinement sequence:
- First prompt: create the one desktop 16:9 screen.
- Second prompt: adjust layout only, for example add a collapsible left sidebar and keep the main table aligned to the content area.
- Third prompt: adjust controls only, for example add search, status filter, priority filter, and the primary action button above the table.
- Fourth prompt: adjust enterprise details only, for example add SharePoint-style status badges and exact table columns.
- Fifth prompt: adjust behavior-specific visual regions only, for example approval timeline, attachment viewer, comments, audit trail, KPI scores, charts, or matrix.

The Stitch prompt must include:
- form nature
- target screen type
- source-backed sections and fields
- attachment upload/viewer requirement, or `Attachments not required` with evidence
- workflow/action requirements
- person/approver/CC requirements
- comments/history/audit requirements
- KPI score, chart, and matrix requirements for dashboards, reports, summaries, or recommendation screens
- SharePoint mapping summary
- required responsive behavior
- Canvas-compatible control expectations
- professional senior-designer quality bar: polished hierarchy, precise spacing, responsive layout, functional operational workflow, and enterprise Microsoft 365 visual quality

Export/download the Stitch HTML or screenshot for each screen. The artifact must be checked against the source-backed behavior criteria for the screen; do not accept a screenshot that omits required fields, sections, workflow actions, attachment behavior, KPI/chart/matrix content, comments, history, or audit trail.

Output:
- `design/stitch/{FormCode}/{ScreenName}.html` or screenshot image

#### Stitch Access Fallback

Use this fallback only when live Stitch is not accessible from the current environment.

Fallback rules:
- Stop before production `.pa.yaml` generation and report that live Stitch cannot be accessed.
- Ask for user approval to continue with a substitute visual artifact.
- Record the access issue, approval, substitute artifact path, and risk in `screen-registry.csv` and `form-build-readiness-report.md`.
- Mark affected screens as `Fallback - Needs Stitch validation`.
- When live Stitch becomes available, replace the substitute artifact with downloaded Stitch output and re-run Canvas YAML generation/audit.

### Stage 7: Canvas YAML Generation

Use `canvas-apps-ui-gen` with the downloaded Stitch artifact.

Rules:
- Follow the downloaded Stitch visual design 1:1 for layout, spacing, hierarchy, card positions, workflow placement, KPI/chart/matrix placement, and visual rhythm.
- Do not generate production `.pa.yaml` from text-only Stitch prompts or design contracts unless the Stitch Access Fallback has been explicitly approved and documented.
- Change only text labels, field names, data bindings, formulas, and business wording required by report.txt evidence and SharePoint mapping.
- Use source/report and SharePoint mapping for real labels, bindings, formulas, and actions.
- Prefer `Office365Users` for real people UI.
- Use `HTML Text`/`HtmlViewer` for read-only workflow/timeline/rich visual parity when native controls are not enough, including attachment/comment/audit layouts, preview panels, KPI/charts/matrices, and polished typography.
- Keep workflow logic in Power Fx/flows, not HTML.
- Keep data entry, upload, approval decisions, navigation, and workflow actions in native Canvas controls or flows, not HTML.

Output:
- draft production `.pa.yaml`

### Stage 8: Power Fx Formula Build

Apply `.github/instructions/canvas-pa-yaml.instructions.md` (Sections C-H).

Build:
- `OnVisible`
- gallery `Items`
- defaults
- create/update `Patch`
- workflow actions
- status transitions
- validation
- `Visible` / `DisplayMode`
- people/profile lookups
- navigation
- attachment upload/viewer behavior
- comments, history, and audit-trail behavior where required
- KPI score, chart, and matrix formulas where required

Rules:
- Always filter department MainDB lists by `FormCode`.
- Always use `.Value` for SharePoint Choice columns.
- Use full SharePoint Person object shape for person writes.
- Use multiline YAML block scalars for complex formulas.

Output:
- formula-complete `.pa.yaml`

### Stage 9: PA YAML Audit

Use `pa-yaml-reference` while authoring and `pa-yaml-compliance-auditor` before handoff.

Required pass gates:
- Source Code v3.0 structure.
- Screen properties under `Properties`.
- No unsupported control/property/version.
- No duplicate controls/properties/screens.
- All formulas start with `=`.
- Data sources declared at app level, not inside screen files.
- Control names follow project convention.
- No placeholder data where real schema exists.
- Accessibility and layout integrity are acceptable.
- Attachment upload/viewer is present or explicitly marked `Not required`.
- Screenshot/design acceptance criteria are satisfied for section behavior and logic.
- Stitch visual parity is preserved except where source labels, field names, formulas, or bindings require changes.

Fix all audit failures before moving to the next screen.

### Stage 10: Screen-by-Screen Completion Loop

For each row in `screen-registry.csv`:
1. Generate or update exactly one target screen.
2. Build formulas.
3. Audit and fix.
4. Update registry status.
5. Confirm no duplicate screen/file/control names.
6. Confirm navigation consistency.
7. Confirm all workflow/form logic is implemented or logged as `Needs confirmation`.
8. Confirm attachment upload/viewer is present or explicitly `Not required`.
9. Confirm the latest screenshot/design artifact satisfies the screen's section behavior and logic criteria.
10. Confirm dashboard/report screens include required KPI scores, charts, and matrices.

Continue until every required screen is complete.

### Stage 11: Final Readiness

Verify:
- all required screens exist exactly once
- all fields are mapped or provisioned by CSV
- all formulas use mapped columns
- attachment upload/viewer exists for every applicable form
- workflow actions are implemented or explicitly deferred
- required KPI scores, charts, matrices, comments, history, preview, and audit-trail regions are present where applicable
- generated screenshots/design artifacts satisfy section behavior and logic criteria
- PA YAML audit passes
- app is ready for MSAPP packing/validation through Workflow 11

Output:
- `form-build-readiness-report.md`

## Completion Criteria

The pipeline is complete only when the form/app has:
- source evidence report
- form nature assessment
- complete field and logic inventory
- SharePoint mapping register
- PnP CSV for unmapped fields
- screen architecture and registry
- Stitch design artifacts
- screenshot/design acceptance notes proving section behavior and logic coverage
- production `.pa.yaml` screens
- Power Fx formulas
- PA YAML audit pass
- final readiness report