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

Canvas App Migration Session

Name: canvas-migration-session
Author: migoamigoea-star

Invoke @canvas-migration-architect to start a full Canvas App migration pipeline.

Goal

Convert the existing TSX Code App into a maintainable Power Apps Canvas App using:

Standard connectors only (SharePoint, Office 365 Users, Office 365 Outlook)
No Dataverse, SQL, custom connectors, or premium connectors
Power Automate flows for approval/workflow/notifications
Reusable Canvas components for consistent UX
XML/DXL, TXT, PDF, SharePoint schema, and TSX/code as source evidence
The IOI professional UI design system and mandatory container hierarchy

🆕 Canvas Screen Requirement Spec: Before designing or implementing any screen, the architect and builder agents MUST read design/IOI-CANVAS-SCREEN-SPEC.md. This 26-section spec is the authoritative reference for:

Layout shell dimensions (§2): Header H=42, Sidebar W=194-224, Content X=220-240

Typography mapping (§3): Every Stitch CSS size → Canvas PA Size

Color system (§4): gblITTheme with 16 tokens — must use theme, not hardcoded

Container strategy (§5): AutoLayout rules, LayoutMinWidth=0 enforcement

Control properties (§6): 15 controls with exact recommended values

Screen templates (§7, §23): Index, New, Detail, Approval, My Tasks, Action Hub, Dashboard

KPI cards (§8), Tab bar (§9), Workflow timeline (§10)

Responsive patterns (§18): sidebar collapse, column breakpoints

Error/empty/loading states (§19), validation (§20), people (§21)

HtmlViewer rules (§25): ✅/❌ usage, padding =0, performance

PAC CLI commands (§26): validate/pack/unpack + error table

20-point checklist (§16) + 18 compliance gates (§13)

Every screen designed or built in this migration must conform to these standards. Non-compliant output must be revised before handoff.

Use TSX as reference only. XML/TXT/PDF define source business structure, SharePoint schema defines persistence, and the Canvas design system defines the final UI. Do not invent missing business logic; mark unconfirmed rules as Needs confirmation.

Pipeline Steps

Run each step sequentially. Use /memory session to track progress.

Step 1 — Inventory

List every XML/DXL, TXT, PDF, screenshot/PNG, SharePoint schema, generated service/model, and TSX page/module available for each form/app.
Classify each as: Index | New | View | Detail | Edit | Approval | Dashboard

Step 2 — Per-Screen Analysis

First determine whether the request is:
- New screen from screenshot/reference
- Existing screen modification

For each screen, analyze the 20 dimensions:
1. Screen purpose
2. Department/form name
3. Screen type
4. Data source used
5. SharePoint list name
6. Required columns
7. System-generated columns
8. Editable columns
9. Computed/read-only columns
10. Field types
11. Lookup/person/choice fields
12. Validation rules
13. Conditional visibility
14. Required/optional behavior
15. Button actions
16. Approval/workflow behavior
17. Role-based access
18. Navigation logic
19. Loading/error/empty state behavior
20. Canvas App replacement design

If screenshot evidence exists, also extract:
- structure and section order
- font sizes and typography cues
- spacing/padding/gaps
- workflow presentation style
- people presentation style
- areas that require `HTML Text` for close visual parity

Step 3 — SharePoint Schema Mapping

For each SharePoint list used:
- List name and target site URL
- Column mapping: Display Name, Internal Name, Type, Required, Editable, System
- Choice column options
- Lookup relationships
- Person/group column config

Step 4 — Canvas Screen Design

For each Canvas screen:
- Full mandatory container hierarchy before controls
- Layout (vertical/horizontal containers, galleries, forms, cards)
- Controls (ModernTextInput, ModernDropdown, ModernButton, etc.)
- Navigation (Navigate, Back, variables)
- Responsive behavior (FillPortions, stretch, scroll)
- Typography, color, background, spacing, border, and status badge rules
- LoadingContainer, EmptyStateContainer, ErrorStateContainer, validation, and success behavior
- Match screenshot structure and font sizing as closely as Canvas allows
- Use `Office365Users` patterns when the UI needs to show people
- Use `HTML Text` for workflow or rich formatted display when native controls
  cannot achieve close enough visual parity
- Record any exact-match limitations explicitly

Step 5 — Power Fx Drafting

Draft key formulas:
- OnVisible: screen init, variables, record loading
- OnSelect: Patch, SubmitForm, IfError, Notify
- Items: gallery/filter delegation-safe queries
- Default: field defaults
- DisplayMode: Edit/View/Disabled
- Visible: conditional field visibility
- Valid: field validation rules

Step 6 — Power Automate Design

For each workflow:
- Trigger (SharePoint item created/modified)
- Conditions (status change, stage transition)
- Actions (send email, update item, deep link)
- Connectors (SharePoint, Office 365 Outlook)

Step 7 — Component Architecture

Design reusable Canvas components:
- Header: title, user info, back nav
- StatusBadge: stage indicator
- ApprovalTimeline: workflow history
- ActionPanel: contextual action buttons

Step 8 — Risk Register

Maintain a live risk table:
| # | Issue | Severity | Resolution |

Step 9 — Implementation Plan

Produce a build task list with:

Task ID, description, dependencies
Effort estimate (Story Points or hours)
Assigned component/screen
Acceptance criteria

Output Format

Each step must produce structured artifacts in canvas-migration-design/ and the required XML UI design reports:

canvas-migration-design/
├── 01-inventory.md
├── 02-per-screen-analysis/
│   ├── ITSSR-New.md
│   ├── ITSSR-List.md
│   ├── ITSSR-Detail.md
│   └── ...
├── 03-sharepoint-mapping.md
├── 04-canvas-screen-design.md
├── 05-powerfx-formulas.md
├── 06-power-automate-design.md
├── 07-component-architecture.md
├── 08-risk-register.md
└── 09-implementation-plan.md

Required reports:

XML_UI_DESIGN_MASTER_REPORT.md
XML_FORM_UI_INVENTORY.xlsx
XML_UI_GAP_REGISTER.xlsx
UI_DESIGN_SYSTEM_AND_SCREEN_STANDARD.md
canvas-migration-design/02-per-screen-analysis/<Form>-<Screen>.md
canvas-migration-design/04-canvas-screen-design/<Form>-blueprint.md

Every per-form blueprint must include:

Form name, department, site, source files, purpose, build readiness
Screen list: dashboard, view list, new form, detail, approval panel if confirmed, admin/config if needed
Container hierarchy: AppRootContainer, HeaderContainer, BodyContainer, SidebarContainer, MainContentContainer, PageHeaderContainer, FormContainer, SectionContainer, FieldRowContainer, FieldContainer, ActionBarContainer, WorkflowTimelineContainer, LoadingContainer, EmptyStateContainer, ErrorStateContainer, CommentsContainer, AttachmentContainer, AuditHistoryContainer
Typography and color rules from UI_DESIGN_SYSTEM_AND_SCREEN_STANDARD.md
Field inventory with SharePoint internal column mapping
Section design, action logic, workflow timeline, responsive behavior, loading/empty/error/success/validation states
Gaps and confirmation required

Key Constraints Reminder

❌ No Dataverse
❌ No SQL
❌ No Azure services
❌ No custom connector
❌ No HTTP premium action
❌ No premium connector dependency
✅ SharePoint Lists only
✅ Office 365 Users (people/profile)
✅ Office 365 Outlook (email)
✅ Power Automate standard connectors

UI and Evidence Constraints

Do not assume approval. Classify each form as: No approval, Notification only, Single-level approval, Multi-level approval, or Unknown workflow.
Do not add approval buttons unless approval is confirmed by source evidence.
Every field must be inside a FieldContainer.
Every screen must include loading, empty, error, validation, and success states.
Use Segoe UI typography, approved IOI colors, 1180px main max width, 64px header, 260px desktop sidebar, 40px controls/buttons, and responsive desktop/tablet/mobile behavior.
When a screenshot is provided, replicate it 1:1 as closely as Power Apps Canvas permits before redesigning.
Preserve exact structure and font size whenever possible; if not possible, state the limitation and closest fallback.
Use Office365Users when the UI needs to show people, approvers, or profile information.
Use HTML Text for workflow/timeline or other rich formatted read-only areas when native controls are not visually sufficient.
Classify build readiness as Ready to Build, Partial Build, Needs Confirmation, or Blocked.

# Canvas App Migration Session > Invoke `@canvas-migration-architect` to start a full Canvas App migration pipeline. ## Goal Convert the existing TSX Code App into a maintainable Power Apps Canvas App using: - Standard connectors only (SharePoint, Office 365 Users, Office 365 Outlook) - No Dataverse, SQL, custom connectors, or premium connectors - Power Automate flows for approval/workflow/notifications - Reusable Canvas components for consistent UX - XML/DXL, TXT, PDF, SharePoint schema, and TSX/code as source evidence - The IOI professional UI design system and mandatory container hierarchy > 🆕 **Canvas Screen Requirement Spec**: Before designing or implementing any > screen, the architect and builder agents MUST read `design/IOI-CANVAS-SCREEN-SPEC.md`. > This 26-section spec is the authoritative reference for: > - Layout shell dimensions (§2): Header H=42, Sidebar W=194-224, Content X=220-240 > - Typography mapping (§3): Every Stitch CSS size → Canvas PA Size > - Color system (§4): `gblITTheme` with 16 tokens — must use theme, not hardcoded > - Container strategy (§5): AutoLayout rules, `LayoutMinWidth=0` enforcement > - Control properties (§6): 15 controls with exact recommended values > - Screen templates (§7, §23): Index, New, Detail, Approval, My Tasks, Action Hub, Dashboard > - KPI cards (§8), Tab bar (§9), Workflow timeline (§10) > - Responsive patterns (§18): sidebar collapse, column breakpoints > - Error/empty/loading states (§19), validation (§20), people (§21) > - HtmlViewer rules (§25): ✅/❌ usage, padding `=0`, performance > - PAC CLI commands (§26): validate/pack/unpack + error table > - 20-point checklist (§16) + 18 compliance gates (§13) > > **Every screen designed or built in this migration must conform to these > standards. Non-compliant output must be revised before handoff.** Use TSX as reference only. XML/TXT/PDF define source business structure, SharePoint schema defines persistence, and the Canvas design system defines the final UI. Do not invent missing business logic; mark unconfirmed rules as `Needs confirmation`. ## Pipeline Steps Run each step sequentially. Use `/memory session` to track progress. ### Step 1 — Inventory ``` List every XML/DXL, TXT, PDF, screenshot/PNG, SharePoint schema, generated service/model, and TSX page/module available for each form/app. Classify each as: Index | New | View | Detail | Edit | Approval | Dashboard ``` ### Step 2 — Per-Screen Analysis ``` First determine whether the request is: - New screen from screenshot/reference - Existing screen modification For each screen, analyze the 20 dimensions: 1. Screen purpose 2. Department/form name 3. Screen type 4. Data source used 5. SharePoint list name 6. Required columns 7. System-generated columns 8. Editable columns 9. Computed/read-only columns 10. Field types 11. Lookup/person/choice fields 12. Validation rules 13. Conditional visibility 14. Required/optional behavior 15. Button actions 16. Approval/workflow behavior 17. Role-based access 18. Navigation logic 19. Loading/error/empty state behavior 20. Canvas App replacement design If screenshot evidence exists, also extract: - structure and section order - font sizes and typography cues - spacing/padding/gaps - workflow presentation style - people presentation style - areas that require `HTML Text` for close visual parity ``` ### Step 3 — SharePoint Schema Mapping ``` For each SharePoint list used: - List name and target site URL - Column mapping: Display Name, Internal Name, Type, Required, Editable, System - Choice column options - Lookup relationships - Person/group column config ``` ### Step 4 — Canvas Screen Design ``` For each Canvas screen: - Full mandatory container hierarchy before controls - Layout (vertical/horizontal containers, galleries, forms, cards) - Controls (ModernTextInput, ModernDropdown, ModernButton, etc.) - Navigation (Navigate, Back, variables) - Responsive behavior (FillPortions, stretch, scroll) - Typography, color, background, spacing, border, and status badge rules - LoadingContainer, EmptyStateContainer, ErrorStateContainer, validation, and success behavior - Match screenshot structure and font sizing as closely as Canvas allows - Use `Office365Users` patterns when the UI needs to show people - Use `HTML Text` for workflow or rich formatted display when native controls cannot achieve close enough visual parity - Record any exact-match limitations explicitly ``` ### Step 5 — Power Fx Drafting ``` Draft key formulas: - OnVisible: screen init, variables, record loading - OnSelect: Patch, SubmitForm, IfError, Notify - Items: gallery/filter delegation-safe queries - Default: field defaults - DisplayMode: Edit/View/Disabled - Visible: conditional field visibility - Valid: field validation rules ``` ### Step 6 — Power Automate Design ``` For each workflow: - Trigger (SharePoint item created/modified) - Conditions (status change, stage transition) - Actions (send email, update item, deep link) - Connectors (SharePoint, Office 365 Outlook) ``` ### Step 7 — Component Architecture ``` Design reusable Canvas components: - Header: title, user info, back nav - StatusBadge: stage indicator - ApprovalTimeline: workflow history - ActionPanel: contextual action buttons ``` ### Step 8 — Risk Register ``` Maintain a live risk table: | # | Issue | Severity | Resolution | ``` ### Step 9 — Implementation Plan Produce a build task list with: - Task ID, description, dependencies - Effort estimate (Story Points or hours) - Assigned component/screen - Acceptance criteria ## Output Format Each step must produce structured artifacts in `canvas-migration-design/` and the required XML UI design reports: ``` canvas-migration-design/ ├── 01-inventory.md ├── 02-per-screen-analysis/ │ ├── ITSSR-New.md │ ├── ITSSR-List.md │ ├── ITSSR-Detail.md │ └── ... ├── 03-sharepoint-mapping.md ├── 04-canvas-screen-design.md ├── 05-powerfx-formulas.md ├── 06-power-automate-design.md ├── 07-component-architecture.md ├── 08-risk-register.md └── 09-implementation-plan.md ``` Required reports: ``` XML_UI_DESIGN_MASTER_REPORT.md XML_FORM_UI_INVENTORY.xlsx XML_UI_GAP_REGISTER.xlsx UI_DESIGN_SYSTEM_AND_SCREEN_STANDARD.md canvas-migration-design/02-per-screen-analysis/<Form>-<Screen>.md canvas-migration-design/04-canvas-screen-design/<Form>-blueprint.md ``` Every per-form blueprint must include: - Form name, department, site, source files, purpose, build readiness - Screen list: dashboard, view list, new form, detail, approval panel if confirmed, admin/config if needed - Container hierarchy: AppRootContainer, HeaderContainer, BodyContainer, SidebarContainer, MainContentContainer, PageHeaderContainer, FormContainer, SectionContainer, FieldRowContainer, FieldContainer, ActionBarContainer, WorkflowTimelineContainer, LoadingContainer, EmptyStateContainer, ErrorStateContainer, CommentsContainer, AttachmentContainer, AuditHistoryContainer - Typography and color rules from `UI_DESIGN_SYSTEM_AND_SCREEN_STANDARD.md` - Field inventory with SharePoint internal column mapping - Section design, action logic, workflow timeline, responsive behavior, loading/empty/error/success/validation states - Gaps and confirmation required ## Key Constraints Reminder - ❌ No Dataverse - ❌ No SQL - ❌ No Azure services - ❌ No custom connector - ❌ No HTTP premium action - ❌ No premium connector dependency - ✅ SharePoint Lists only - ✅ Office 365 Users (people/profile) - ✅ Office 365 Outlook (email) - ✅ Power Automate standard connectors ## UI and Evidence Constraints - Do not assume approval. Classify each form as: No approval, Notification only, Single-level approval, Multi-level approval, or Unknown workflow. - Do not add approval buttons unless approval is confirmed by source evidence. - Every field must be inside a `FieldContainer`. - Every screen must include loading, empty, error, validation, and success states. - Use Segoe UI typography, approved IOI colors, 1180px main max width, 64px header, 260px desktop sidebar, 40px controls/buttons, and responsive desktop/tablet/mobile behavior. - When a screenshot is provided, replicate it 1:1 as closely as Power Apps Canvas permits before redesigning. - Preserve exact structure and font size whenever possible; if not possible, state the limitation and closest fallback. - Use `Office365Users` when the UI needs to show people, approvers, or profile information. - Use `HTML Text` for workflow/timeline or other rich formatted read-only areas when native controls are not visually sufficient. - Classify build readiness as Ready to Build, Partial Build, Needs Confirmation, or Blocked.

{ "prompt": "# Canvas App Migration Session\n\n> Invoke `@canvas-migration-architect` to start a full Canvas App migration pipeline.\n\n## Goal\n\nConvert the existing TSX Code App into a maintainable Power Apps Canvas App using:\n- Standard connectors only (SharePoint, Office 365 Users, Office 365 Outlook)\n- No Dataverse, SQL, custom connectors, or premium connectors\n- Power Automate flows for approval/workflow/notifications\n- Reusable Canvas components for consistent UX\n- XML/DXL, TXT, PDF, SharePoint schema, and TSX/code as source evidence\n- The IOI professional UI design system and mandatory container hierarchy\n\n> 🆕 **Canvas Screen Requirement Spec**: Before designing or implementing any\n> screen, the architect and builder agents MUST read `design/IOI-CANVAS-SCREEN-SPEC.md`.\n> This 26-section spec is the authoritative reference for:\n> - Layout shell dimensions (§2): Header H=42, Sidebar W=194-224, Content X=220-240\n> - Typography mapping (§3): Every Stitch CSS size → Canvas PA Size\n> - Color system (§4): `gblITTheme` with 16 tokens — must use theme, not hardcoded\n> - Container strategy (§5): AutoLayout rules, `LayoutMinWidth=0` enforcement\n> - Control properties (§6): 15 controls with exact recommended values\n> - Screen templates (§7, §23): Index, New, Detail, Approval, My Tasks, Action Hub, Dashboard\n> - KPI cards (§8), Tab bar (§9), Workflow timeline (§10)\n> - Responsive patterns (§18): sidebar collapse, column breakpoints\n> - Error/empty/loading states (§19), validation (§20), people (§21)\n> - HtmlViewer rules (§25): ✅/❌ usage, padding `=0`, performance\n> - PAC CLI commands (§26): validate/pack/unpack + error table\n> - 20-point checklist (§16) + 18 compliance gates (§13)\n>\n> **Every screen designed or built in this migration must conform to these\n> standards. Non-compliant output must be revised before handoff.**\n\nUse TSX as reference only. XML/TXT/PDF define source business structure, SharePoint schema defines persistence, and the Canvas design system defines the final UI. Do not invent missing business logic; mark unconfirmed rules as `Needs confirmation`.\n\n## Pipeline Steps\n\nRun each step sequentially. Use `/memory session` to track progress.\n\n### Step 1 — Inventory\n\n```\nList every XML/DXL, TXT, PDF, screenshot/PNG, SharePoint schema, generated service/model, and TSX page/module available for each form/app.\nClassify each as: Index | New | View | Detail | Edit | Approval | Dashboard\n```\n\n### Step 2 — Per-Screen Analysis\n\n```\nFirst determine whether the request is:\n- New screen from screenshot/reference\n- Existing screen modification\n\nFor each screen, analyze the 20 dimensions:\n1. Screen purpose\n2. Department/form name\n3. Screen type\n4. Data source used\n5. SharePoint list name\n6. Required columns\n7. System-generated columns\n8. Editable columns\n9. Computed/read-only columns\n10. Field types\n11. Lookup/person/choice fields\n12. Validation rules\n13. Conditional visibility\n14. Required/optional behavior\n15. Button actions\n16. Approval/workflow behavior\n17. Role-based access\n18. Navigation logic\n19. Loading/error/empty state behavior\n20. Canvas App replacement design\n\nIf screenshot evidence exists, also extract:\n- structure and section order\n- font sizes and typography cues\n- spacing/padding/gaps\n- workflow presentation style\n- people presentation style\n- areas that require `HTML Text` for close visual parity\n```\n\n### Step 3 — SharePoint Schema Mapping\n\n```\nFor each SharePoint list used:\n- List name and target site URL\n- Column mapping: Display Name, Internal Name, Type, Required, Editable, System\n- Choice column options\n- Lookup relationships\n- Person/group column config\n```\n\n### Step 4 — Canvas Screen Design\n\n```\nFor each Canvas screen:\n- Full mandatory container hierarchy before controls\n- Layout (vertical/horizontal containers, galleries, forms, cards)\n- Controls (ModernTextInput, ModernDropdown, ModernButton, etc.)\n- Navigation (Navigate, Back, variables)\n- Responsive behavior (FillPortions, stretch, scroll)\n- Typography, color, background, spacing, border, and status badge rules\n- LoadingContainer, EmptyStateContainer, ErrorStateContainer, validation, and success behavior\n- Match screenshot structure and font sizing as closely as Canvas allows\n- Use `Office365Users` patterns when the UI needs to show people\n- Use `HTML Text` for workflow or rich formatted display when native controls\n cannot achieve close enough visual parity\n- Record any exact-match limitations explicitly\n```\n\n### Step 5 — Power Fx Drafting\n\n```\nDraft key formulas:\n- OnVisible: screen init, variables, record loading\n- OnSelect: Patch, SubmitForm, IfError, Notify\n- Items: gallery/filter delegation-safe queries\n- Default: field defaults\n- DisplayMode: Edit/View/Disabled\n- Visible: conditional field visibility\n- Valid: field validation rules\n```\n\n### Step 6 — Power Automate Design\n\n```\nFor each workflow:\n- Trigger (SharePoint item created/modified)\n- Conditions (status change, stage transition)\n- Actions (send email, update item, deep link)\n- Connectors (SharePoint, Office 365 Outlook)\n```\n\n### Step 7 — Component Architecture\n\n```\nDesign reusable Canvas components:\n- Header: title, user info, back nav\n- StatusBadge: stage indicator\n- ApprovalTimeline: workflow history\n- ActionPanel: contextual action buttons\n```\n\n### Step 8 — Risk Register\n\n```\nMaintain a live risk table:\n| # | Issue | Severity | Resolution |\n```\n\n### Step 9 — Implementation Plan\n\nProduce a build task list with:\n- Task ID, description, dependencies\n- Effort estimate (Story Points or hours)\n- Assigned component/screen\n- Acceptance criteria\n\n## Output Format\n\nEach step must produce structured artifacts in `canvas-migration-design/` and the required XML UI design reports:\n\n```\ncanvas-migration-design/\n├── 01-inventory.md\n├── 02-per-screen-analysis/\n│ ├── ITSSR-New.md\n│ ├── ITSSR-List.md\n│ ├── ITSSR-Detail.md\n│ └── ...\n├── 03-sharepoint-mapping.md\n├── 04-canvas-screen-design.md\n├── 05-powerfx-formulas.md\n├── 06-power-automate-design.md\n├── 07-component-architecture.md\n├── 08-risk-register.md\n└── 09-implementation-plan.md\n```\n\nRequired reports:\n\n```\nXML_UI_DESIGN_MASTER_REPORT.md\nXML_FORM_UI_INVENTORY.xlsx\nXML_UI_GAP_REGISTER.xlsx\nUI_DESIGN_SYSTEM_AND_SCREEN_STANDARD.md\ncanvas-migration-design/02-per-screen-analysis/<Form>-<Screen>.md\ncanvas-migration-design/04-canvas-screen-design/<Form>-blueprint.md\n```\n\nEvery per-form blueprint must include:\n- Form name, department, site, source files, purpose, build readiness\n- Screen list: dashboard, view list, new form, detail, approval panel if confirmed, admin/config if needed\n- Container hierarchy: AppRootContainer, HeaderContainer, BodyContainer, SidebarContainer, MainContentContainer, PageHeaderContainer, FormContainer, SectionContainer, FieldRowContainer, FieldContainer, ActionBarContainer, WorkflowTimelineContainer, LoadingContainer, EmptyStateContainer, ErrorStateContainer, CommentsContainer, AttachmentContainer, AuditHistoryContainer\n- Typography and color rules from `UI_DESIGN_SYSTEM_AND_SCREEN_STANDARD.md`\n- Field inventory with SharePoint internal column mapping\n- Section design, action logic, workflow timeline, responsive behavior, loading/empty/error/success/validation states\n- Gaps and confirmation required\n\n## Key Constraints Reminder\n\n- ❌ No Dataverse\n- ❌ No SQL\n- ❌ No Azure services\n- ❌ No custom connector\n- ❌ No HTTP premium action\n- ❌ No premium connector dependency\n- ✅ SharePoint Lists only\n- ✅ Office 365 Users (people/profile)\n- ✅ Office 365 Outlook (email)\n- ✅ Power Automate standard connectors\n\n## UI and Evidence Constraints\n\n- Do not assume approval. Classify each form as: No approval, Notification only, Single-level approval, Multi-level approval, or Unknown workflow.\n- Do not add approval buttons unless approval is confirmed by source evidence.\n- Every field must be inside a `FieldContainer`.\n- Every screen must include loading, empty, error, validation, and success states.\n- Use Segoe UI typography, approved IOI colors, 1180px main max width, 64px header, 260px desktop sidebar, 40px controls/buttons, and responsive desktop/tablet/mobile behavior.\n- When a screenshot is provided, replicate it 1:1 as closely as Power Apps Canvas permits before redesigning.\n- Preserve exact structure and font size whenever possible; if not possible, state the limitation and closest fallback.\n- Use `Office365Users` when the UI needs to show people, approvers, or profile information.\n- Use `HTML Text` for workflow/timeline or other rich formatted read-only areas when native controls are not visually sufficient.\n- Classify build readiness as Ready to Build, Partial Build, Needs Confirmation, or Blocked.", "variables": [], "notes": "Convert the existing TSX Code App into a maintainable Power Apps Canvas App using: - Standard connectors only (SharePoint, Office 365 Users, Office 365 Outlook) - No Dataverse, SQL, custom connectors, or premium connectors - Power Automate flows for approval/workflow/notifications - Reusable Canvas components for consistent UX - XML/DXL, TXT, PDF, SharePoint schema, and TSX/code as source evidence - The IOI professional UI design system and mandatory container hierarchy", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/migoamigoea-star/ioi-docs-uploads", "path": ".github/prompts/canvas-migration-session.prompt.md", "ref": "a1b8baaa6c43f0a06fd8cd7602abeebdf46a14dc", "url": "https://github.com/migoamigoea-star/ioi-docs-uploads/blob/a1b8baaa6c43f0a06fd8cd7602abeebdf46a14dc/.github/prompts/canvas-migration-session.prompt.md", "key": "migoamigoea-star/ioi-docs-uploads/.github/prompts/canvas-migration-session.prompt.md" } } }

canvas-migration-session

About