# JIFFYAI Gift Cards Documentation Source Pack

This folder is a documentation-ready record of capability testing in the production workspace at `https://giftcards.us.prod.phoenix.jiffy.ai/dashboard` on 4–5 August 2026.

## SR-first application principle

Phoenix applications should be understood through a **Service Request first** model, especially when they are complex or stateful. The Service Request is the operational backbone; screens, forms, entities, approvals, workflows, documents, SLA, notifications, servicing, and audit history are capabilities around that request lifecycle.

In this model, an application is not merely a collection of pages and CRUD operations. It receives or creates a request, progresses it through controlled task states, assigns responsibility, performs work, records decisions, handles exceptions, and preserves an auditable outcome. The production audit therefore treats generic entity-backed behavior as incomplete whenever a native Service Request should be the foundation.

The pack deliberately separates four evidence levels:

1. **Executed** — a production action was completed and its result verified.
2. **Observed** — the UI and available controls were inspected, but no persistent or external action was performed.
3. **Simulated** — the generated app displayed a local UI effect, not a platform notification, email, workflow, or Service Request.
4. **Knowledge Base** — the capability is described by official Phoenix documentation but was not available for end-to-end execution in this tenant.

## Source files

- [Build a small app with AI](./AI_BUILDER_GUIDE.md) — quick AI path and iterative refinement.
- [Capability catalog](./CAPABILITY_CATALOG.md) — workspace and app-level reference.
- [Documents and bundles](./DOCUMENTS_AND_BUNDLES.md) — upload, AI classification, schema, extraction, approval, publishing, and bundle dependency.
- [Service Requests and notifications](./SERVICE_REQUESTS_AND_NOTIFICATIONS.md) — the AI-generated SR-like app, native Service Request designer, approval branches, task states, SLA/status behavior, and notification semantics.
- [Schedules and email](./SCHEDULES_AND_EMAIL.md) — scheduler fields, workflow selection, email subscription surfaces, and safety boundaries.
- [Knowledge Base crosswalk](./KNOWLEDGE_BASE_CROSSWALK.md) — official Phoenix documentation reconciled with production observations.
- [Production test report](./TEST_REPORT.md) — scenario results and limitations.
- [Defect register](./DEFECT_REGISTER.md) — every unassigned PHX bug raised during the audit.
- [Screenshot manifest](./SCREENSHOT_MANIFEST.md) — image captions and suggested placement.
- [`screenshots/`](./screenshots/) — captured PNG evidence.

## Test artifacts created

| Artifact | Purpose | State |
|---|---|---|
| **AI Gift Card Quickstart** | Fast AI builder baseline | Two pages; all 1,375 automated tests passed |
| **Gift Card SR Operations Lab** | Persistent data, request history, approval, fulfillment, attachments, and notification scenarios | Two pages; 1,396 passed and 1 failed; several runtime defects documented |
| **Gift Card Service Request** document type | AI document classification, schema, extraction, and approval | Approved; publication blocked by HTTP 500 |
| **JIFFYAI Gift Card Service Request Standard** | Generated document variant | Draft because parent document-type publication failed |
| **QA Inactive Hourly Document Extraction** | Scheduler persistence test | Saved inactive; interval and edit-hydration defects documented |
| **QA Gift Card Service Request** | Native Service Request designer and AI workflow-generation test | Type, five task states, Tenant Admin approval, approve/reject jumps, and Return saved; runtime test needs a valid `srInstanceId` |

The deprecated step-by-step comparison app, **Gift Card Experience Documentation Lab**, was inspected only to identify the legacy visual-editor surface.

## Headline results

- The AI builder can create and iteratively extend small one- or two-page apps.
- AI document processing completed upload → classification → schema → extraction → approval successfully.
- Document-type publication returned HTTP 500 for two version attempts, blocking the document library, bundle construction, and real workflow/SR use of that document type.
- The first AI-generated SR-like app used a generic `service_request` entity and saved-query CRUD because no Service-Request-tagged workflow was available to that generation path.
- Under the SR-first architecture principle, that generic implementation is a fallback/divergence, not the preferred foundation for a complex application.
- The app's native editor separately allowed a real Service Request type, task states, execution-history surface, and approval flow to be created.
- Native Service Request AI initially generated a legacy `srInstanceId` parameter value and failed to save; a repair prompt succeeded. It also fabricated empty Compose placeholders for unavailable status/notification actions. These are [PHX-6023](https://jiffy-ai.atlassian.net/browse/PHX-6023) and [PHX-6024](https://jiffy-ai.atlassian.net/browse/PHX-6024).
- The Notification functional node was absent from both current-app and platform palettes, despite Sprint 16 documentation saying it had been built. See [PHX-6025](https://jiffy-ai.atlassian.net/browse/PHX-6025).
- SLA Tracking exposed no configurable arguments; production evidence was added to existing [PHX-5832](https://jiffy-ai.atlassian.net/browse/PHX-5832). Status-tracking evidence was added to [PHX-5831](https://jiffy-ai.atlassian.net/browse/PHX-5831).
- Attachment upload to app-scoped Jiffy Drive and fulfillment update succeeded.
- Request creation, approval, rejection, search, and status filtering exposed reproducible failures.
- In-app and email notifications in the generated app were **simulated UI messages**, not actual platform delivery.
- An inactive schedule was saved against the platform `Document Extraction` workflow, but a 24-hour interval was persisted as 23 hours, edit failed to restore relationship fields, and search did not filter. The search regression is [PHX-6021](https://jiffy-ai.atlassian.net/browse/PHX-6021).
- Email Rules exposes workflow routing only, while its page guidance still promises workflow or webhook routing. See [PHX-6022](https://jiffy-ai.atlassian.net/browse/PHX-6022).
- New failures were filed as unassigned PHX bugs; exact existing status/SLA items received production evidence instead of duplicate issues.

## Recommended documentation-site navigation

1. Platform overview and evidence labels
2. Create and refine an app with AI
3. Work with entities, saved queries, and app-scoped files
4. Process a document with AI
5. Publish document types and build bundles
6. Model Service Requests and approval paths
7. Configure workflows, notifications, and email
8. Create and manage schedules
9. Access control, app settings, and workspace administration
10. Troubleshooting and known defects

![Approved document with extracted data](./screenshots/61-document-approved.png)

![Inactive workflow schedule](./screenshots/86-schedule-inactive-created.png)