mirror of https://github.com/docusealco/docuseal
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
429 lines
117 KiB
429 lines
117 KiB
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="UTF-8">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|
<title>FloDoc User Stories - Epic Details</title>
|
|
<style>
|
|
* { margin: 0; padding: 0; box-sizing: border-box; }
|
|
body { font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif; background: linear-gradient(135deg, #667eea 0%, #764ba2 100%); height: 100vh; overflow: hidden; }
|
|
.slide-container { width: 100vw; height: 100vh; display: flex; justify-content: center; align-items: center; padding: 2rem; }
|
|
.slide { width: 90%; max-width: 1200px; height: 90%; background: white; border-radius: 20px; box-shadow: 0 20px 60px rgba(0,0,0,0.3); padding: 3rem; overflow-y: auto; display: none; animation: fadeIn 0.5s ease-in-out; }
|
|
.slide.active { display: block; }
|
|
@keyframes fadeIn { from { opacity: 0; transform: translateY(20px); } to { opacity: 1; transform: translateY(0); } }
|
|
.slide-header { border-bottom: 3px solid #667eea; padding-bottom: 1rem; margin-bottom: 2rem; }
|
|
.story-number { font-size: 1.2rem; color: #667eea; font-weight: 600; margin-bottom: 0.5rem; }
|
|
.story-title { font-size: 2rem; font-weight: 700; color: #1a202c; line-height: 1.3; }
|
|
.section { margin-bottom: 2rem; }
|
|
.section-title { font-size: 1.3rem; font-weight: 600; color: #667eea; margin-bottom: 1rem; display: flex; align-items: center; gap: 0.5rem; }
|
|
.section-title::before { content: ""; width: 4px; height: 24px; background: #667eea; border-radius: 2px; }
|
|
.section-content { background: #f7fafc; padding: 1.5rem; border-radius: 8px; line-height: 1.8; color: #2d3748; font-size: 1rem; }
|
|
.section-content strong { color: #667eea; }
|
|
.section-content ul, .section-content ol { margin-left: 1.5rem; margin-top: 0.5rem; }
|
|
.section-content li { margin-bottom: 0.5rem; }
|
|
.section-content code { background: #edf2f7; padding: 0.2rem 0.4rem; border-radius: 4px; font-family: "Courier New", monospace; font-size: 0.9rem; }
|
|
.navigation { position: fixed; bottom: 2rem; left: 50%; transform: translateX(-50%); background: rgba(255,255,255,0.95); padding: 1rem 2rem; border-radius: 50px; box-shadow: 0 4px 20px rgba(0,0,0,0.2); display: flex; gap: 1rem; align-items: center; z-index: 1000; }
|
|
.nav-btn { background: #667eea; color: white; border: none; padding: 0.75rem 1.5rem; border-radius: 25px; cursor: pointer; font-weight: 600; transition: all 0.3s ease; font-size: 1rem; }
|
|
.nav-btn:hover { background: #5568d3; transform: translateY(-2px); box-shadow: 0 4px 12px rgba(102,126,234,0.4); }
|
|
.nav-btn:disabled { background: #cbd5e0; cursor: not-allowed; transform: none; }
|
|
.nav-btn.secondary { background: #718096; }
|
|
.nav-btn.secondary:hover { background: #4a5568; }
|
|
.progress-bar { position: fixed; top: 0; left: 0; height: 4px; background: #667eea; transition: width 0.3s ease; z-index: 1001; }
|
|
.slide-counter { font-weight: 600; color: #4a5568; min-width: 100px; text-align: center; }
|
|
.slide::-webkit-scrollbar { width: 8px; }
|
|
.slide::-webkit-scrollbar-track { background: #f1f1f1; border-radius: 10px; }
|
|
.slide::-webkit-scrollbar-thumb { background: #667eea; border-radius: 10px; }
|
|
.slide::-webkit-scrollbar-thumb:hover { background: #5568d3; }
|
|
@media (max-width: 768px) { .slide { padding: 1.5rem; width: 95%; } .story-title { font-size: 1.5rem; } .section-title { font-size: 1.1rem; } .section-content { font-size: 0.9rem; padding: 1rem; } .navigation { padding: 0.75rem 1rem; gap: 0.5rem; } .nav-btn { padding: 0.5rem 1rem; font-size: 0.9rem; } }
|
|
.loading { text-align: center; padding: 2rem; color: white; font-size: 1.5rem; }
|
|
</style>
|
|
</head>
|
|
<body>
|
|
<div class="progress-bar" id="progressBar"></div>
|
|
<div id="slidesContainer"><div class="loading">Loading stories...</div></div>
|
|
<div class="navigation" id="navigation" style="display: none;">
|
|
<button class="nav-btn secondary" id="prevBtn" onclick="prevSlide()">← Previous</button>
|
|
<span class="slide-counter" id="slideCounter">1 / 32</span>
|
|
<button class="nav-btn" id="nextBtn" onclick="nextSlide()">Next →</button>
|
|
</div>
|
|
<script>
|
|
const stories = [];
|
|
let currentSlide = 0;
|
|
function initializeSlides() {
|
|
const container = document.getElementById("slidesContainer");
|
|
container.innerHTML = "";
|
|
stories.forEach((story, index) => {
|
|
const slide = document.createElement("div");
|
|
slide.className = "slide";
|
|
slide.id = `slide-${index}`;
|
|
slide.innerHTML = `
|
|
<div class="slide-header">
|
|
<div class="story-number">Story ${story.number}</div>
|
|
<div class="story-title">${story.title}</div>
|
|
</div>
|
|
<div class="section">
|
|
<div class="section-title">User Story</div>
|
|
<div class="section-content">${formatContent(story.user_story)}</div>
|
|
</div>
|
|
<div class="section">
|
|
<div class="section-title">Background</div>
|
|
<div class="section-content">${formatContent(story.background)}</div>
|
|
</div>
|
|
<div class="section">
|
|
<div class="section-title">Acceptance Criteria</div>
|
|
<div class="section-content">${formatContent(story.acceptance)}</div>
|
|
</div>
|
|
`;
|
|
container.appendChild(slide);
|
|
});
|
|
showSlide(0);
|
|
document.getElementById("navigation").style.display = "flex";
|
|
}
|
|
function formatContent(text) {
|
|
if (!text) return "";
|
|
let html = text;
|
|
html = html.replace(/\*\*(.+?)\*\*/g, "<strong>$1</strong>");
|
|
html = html.replace(/^[\*\-]\s+(.+)$/gm, "<li>$1</li>");
|
|
html = html.replace(/(<li>.*<\/li>)/s, "<ul>$1</ul>");
|
|
html = html.replace(/^\d+\.\s+(.+)$/gm, "<li>$1</li>");
|
|
html = html.replace(/(<li>.*<\/li>)/s, "<ul>$1</ul>");
|
|
html = html.replace(/\n\n/g, "</p><p>");
|
|
html = "<p>" + html + "</p>";
|
|
html = html.replace(/<p><ul>/g, "<ul>");
|
|
html = html.replace(/<\/ul><\/p>/g, "</ul>");
|
|
html = html.replace(/<p><\/p>/g, "");
|
|
return html;
|
|
}
|
|
function showSlide(index) {
|
|
const slides = document.querySelectorAll(".slide");
|
|
slides.forEach((slide, i) => { slide.classList.toggle("active", i === index); });
|
|
currentSlide = index;
|
|
updateNavigation();
|
|
updateProgress();
|
|
}
|
|
function updateNavigation() {
|
|
const prevBtn = document.getElementById("prevBtn");
|
|
const nextBtn = document.getElementById("nextBtn");
|
|
const counter = document.getElementById("slideCounter");
|
|
prevBtn.disabled = currentSlide === 0;
|
|
nextBtn.disabled = currentSlide === stories.length - 1;
|
|
counter.textContent = `${currentSlide + 1} / ${stories.length}`;
|
|
}
|
|
function updateProgress() {
|
|
const progress = ((currentSlide + 1) / stories.length) * 100;
|
|
document.getElementById("progressBar").style.width = progress + "%";
|
|
}
|
|
function nextSlide() { if (currentSlide < stories.length - 1) showSlide(currentSlide + 1); }
|
|
function prevSlide() { if (currentSlide > 0) showSlide(currentSlide - 1); }
|
|
document.addEventListener("keydown", (e) => {
|
|
if (e.key === "ArrowRight" || e.key === " ") { e.preventDefault(); nextSlide(); }
|
|
else if (e.key === "ArrowLeft") { e.preventDefault(); prevSlide(); }
|
|
});
|
|
const storiesData = [
|
|
{
|
|
number: "1.1",
|
|
title: "Database Schema Extension",
|
|
user_story: "**As a** system architect,\n**I want** to create the database schema for FloDoc\'s new models,\n**So that** the application has the foundation to support cohort management.",
|
|
background: "Based on the PRD analysis, we need three new tables to support the 3-portal cohort management system:\n- `institutions` - Single training institution (not multi-tenant)\n- `cohorts` - Training program cohorts\n- `cohort_enrollments` - Student enrollments in cohorts\n\nThese tables must integrate with existing DocuSeal tables without breaking existing functionality.",
|
|
acceptance: "**Functional:**\n1. ✅ All three tables created with correct schema\n2. ✅ Foreign key relationships established\n3. ✅ All indexes created for performance\n4. ✅ Migrations are reversible\n5. ✅ No modifications to existing DocuSeal tables\n\n**Integration:**\n1. ✅ IV1: Existing DocuSeal tables remain unchanged\n2. ✅ IV2: New tables can reference existing tables (templates, submissions)\n3. ✅ IV3: Database performance not degraded (verify with EXPLAIN queries)\n\n**Security:**\n1. ✅ All tables include `deleted_at` for soft deletes\n2. ✅ Sensitive fields (emails) are encrypted at rest if required by policy\n3. ✅ Foreign keys prevent orphaned records\n\n**Quality:**\n1. ✅ Migrations follow Rails conventions\n2. ✅ Table and column names are consistent with existing codebase\n3. ✅ All migrations include `down` method for rollback\n4. ✅ Schema changes documented in migration comments",
|
|
},
|
|
{
|
|
number: "1.2",
|
|
title: "Core Models Implementation",
|
|
user_story: "**As a** developer,\n**I want** to create ActiveRecord models for the new FloDoc tables,\n**So that** the application can interact with cohorts and enrollments programmatically.",
|
|
background: "Models must follow existing DocuSeal patterns:\n- Inherit from `ApplicationRecord`\n- Use `strip_attributes` for data cleaning\n- Include soft delete functionality\n- Define proper associations and validations\n- Follow naming conventions",
|
|
acceptance: "**Functional:**\n1. ✅ All three models created with correct class structure\n2. ✅ All associations defined correctly\n3. ✅ All validations implemented\n4. ✅ All scopes defined\n5. ✅ State machine logic correct (if used)\n6. ✅ Model methods work as specified\n7. ✅ FeatureFlag model created with enabled?, enable!, disable! methods\n8. ✅ FeatureFlagCheck concern implemented\n9. ✅ Default flags seeded (flodoc_cohorts, flodoc_portals)\n10. ✅ All FloDoc routes protected by feature flags\n\n**Integration:**\n1. ✅ IV1: Models don\'t break existing DocuSeal models\n2. ✅ IV2: Associations work with existing tables (templates, submissions)\n3. ✅ IV3: Query performance acceptable with 1000+ records\n4. ✅ Feature flags integrate with existing authentication\n\n**Security:**\n1. ✅ No mass assignment vulnerabilities\n2. ✅ Proper attribute whitelisting\n3. ✅ Email validation on all email fields\n4. ✅ Feature flags can disable FloDoc instantly\n\n**Quality:**\n1. ✅ Follow existing code style (RuboCop compliant)\n2. ✅ All methods have YARD comments\n3. ✅ Test coverage > 80%\n4. ✅ No N+1 query issues\n5. ✅ Feature flag tests included",
|
|
},
|
|
{
|
|
number: "1.3",
|
|
title: "Authorization Layer Extension",
|
|
user_story: "**As a** system administrator,\n**I want** the authorization system to support FloDoc roles and permissions,\n**So that** users can only access appropriate cohort management functions.",
|
|
background: "DocuSeal uses Cancancan for authorization. We need to:\n- Extend `Ability` class to handle FloDoc models\n- Define permissions for TP, Student, and Sponsor roles\n- Support ad-hoc access patterns (students/sponsors without accounts)\n- Maintain existing DocuSeal permissions",
|
|
acceptance: "**Functional:**\n1. ✅ Ability class extended with FloDoc permissions\n2. ✅ Ad-hoc access works for students (via token)\n3. ✅ Ad-hoc access works for sponsors (via token)\n4. ✅ TP permissions work correctly\n5. ✅ Admin permissions work correctly\n6. ✅ Existing DocuSeal permissions unchanged\n\n**Integration:**\n1. ✅ IV1: Existing DocuSeal authorization still works\n2. ✅ IV2: New abilities integrate with existing Ability class\n3. ✅ IV3: Authorization checks don\'t add significant overhead\n\n**Security:**\n1. ✅ JWT tokens signed with secret key\n2. ✅ Tokens have expiration (30 days)\n3. ✅ Token verification prevents tampering\n4. ✅ Ad-hoc users can\'t access other cohorts\n5. ✅ Sponsor can\'t access before all students complete\n\n**Quality:**\n1. ✅ Follow existing authorization patterns\n2. ✅ All abilities tested\n3. ✅ Token service has comprehensive tests\n4. ✅ No security bypasses",
|
|
},
|
|
{
|
|
number: "2.1",
|
|
title: "Cohort Creation & Management",
|
|
user_story: "**As a** TP (Training Provider) administrator,\n**I want** to create and manage cohorts with all their configuration details,\n**So that** I can organize students into training programs and prepare them for the signature workflow.",
|
|
background: "Cohort creation is the entry point for the FloDoc workflow. TP administrators need to:\n- Create a cohort by selecting an existing DocuSeal template\n- Define program type (learnership/internship/candidacy)\n- Specify required student documents (ID, matric, tertiary, etc.)\n- Set sponsor email for the review phase\n- Configure cohort metadata and settings\n\nThe cohort acts as a container that orchestrates the entire 3-party signature workflow.",
|
|
acceptance: "**Functional:**\n1. ✅ TP can create cohort with template selection\n2. ✅ TP can specify program type (learnership/internship/candidacy)\n3. ✅ TP can define required student uploads (max 10 types)\n4. ✅ TP can set sponsor email\n5. ✅ TP can add cohort metadata\n6. ✅ TP can edit cohort in draft state\n7. ✅ TP can delete cohort (soft delete)\n8. ✅ All operations logged in audit trail\n\n**Integration:**\n1. ✅ IV1: Cohort creation validates template exists\n2. ✅ IV2: Cohort links correctly to existing template\n3. ✅ IV3: No performance degradation with 100+ cohorts\n\n**Security:**\n1. ✅ Only TP admins can create/manage cohorts\n2. ✅ TP can only manage their institution\'s cohorts\n3. ✅ Sponsor email validation enforced\n4. ✅ Audit logs cannot be tampered with\n\n**Quality:**\n1. ✅ Follow existing service object patterns\n2. ✅ Transactional safety for cohort creation\n3. ✅ Proper error handling and user feedback\n4. ✅ 80% test coverage for service layer",
|
|
},
|
|
{
|
|
number: "2.2",
|
|
title: "TP Signing Phase Logic (High Risk - Prototype First)",
|
|
user_story: "**As a** TP administrator,\n**I want** to sign the first student\'s document and have that signing replicated to all other students in the cohort,\n**So that** I don\'t need to sign each student\'s document individually, saving time and eliminating duplicate sponsor emails.",
|
|
background: "This is the core innovation of FloDoc. The workflow is:\n\n1. **TP Signing Phase**: TP signs ONE student\'s document (with their fields/signatures)\n2. **Duplication**: System duplicates the **completed submission** (not empty template) to remaining students\n3. **Auto-fill**: TP\'s fields and signatures are automatically populated across all student submissions\n4. **Email Management**: Sponsor receives ONE email (when all students are ready), not duplicate emails per submission\n\n**Why Prototype First**: DocuSeal\'s native multi-submission only duplicates empty templates. This story requires custom duplication of pre-filled submissions, which is a high-risk architectural change.\n\n**Prototype Approach**: Build a minimal prototype that:\n- Creates 2-3 test submissions\n- Demonstrates field/signature copying from first to remaining\n- Validates sponsor email delivery logic\n- Then expand to full implementation",
|
|
acceptance: "**Functional:**\n1. ✅ TP can initiate TP signing phase from draft state\n2. ✅ System creates \"seed\" submission for TP to sign\n3. ✅ TP\'s signatures and field values are captured\n4. ✅ System duplicates submission for all pending students\n5. ✅ TP\'s values auto-fill into all student submissions\n6. ✅ Sponsor receives only ONE email when all students ready\n7. ✅ Cohort state transitions correctly through workflow\n\n**Integration:**\n1. ✅ IV1: Doesn\'t break existing submission/submitter logic\n2. ✅ IV2: Submissions correctly linked to cohorments\n3. ✅ IV3: Performance acceptable with 100 students per cohort\n\n**Security:**\n1. ✅ Only TP can initiate TP signing phase\n2. ✅ TP can only sign their institution\'s cohorts\n3. ✅ Pre-filled submissions marked clearly\n4. ✅ Audit trail captures all duplication operations\n\n**Quality:**\n1. ✅ Transactional guarantees for multi-submission creation\n2. ✅ Proper error handling for partial failures\n3. ✅ Debug logging for debugging duplication issues\n4. ✅ 85% test coverage",
|
|
},
|
|
{
|
|
number: "2.3",
|
|
title: "Student Enrollment Management",
|
|
user_story: "**As a** TP administrator,\n**I want** to manage student enrollment in cohorts and bulk-create student submissions,\n**So that** students can access their documents to complete after TP signs.",
|
|
background: "After TP completes signing (Phase 2.2), the system needs to:\n- Create student records in the cohort\n- Set up individual submissions for each student\n- Send email invites (using existing DocuSeal email system)\n- Track student completion status\n\nThe enrollment process uses the existing DocuSeal submission invitation mechanism but adapts it to FloDoc\'s workflow needs.\n\n**Key Requirements:**\n- Bulk enrollment via CSV or manual entry\n- Each student gets their own submission (pre-filled with TP\'s data)\n- Email invites sent via DocuSeal\'s existing email system\n- Student status tracked in cohort_enrollments",
|
|
acceptance: "**Functional:**\n1. ✅ TP can bulk enroll students via CSV or manual entry\n2. ✅ System validates student emails before creating enrollments\n3. ✅ TP can send email invites to all enrolled students\n4. ✅ Students can access their pre-filled documents via link\n5. ✅ System tracks student completion (form fill + upload)\n6. ✅ System auto-moves cohort to \"ready_for_sponsor\" when all complete\n7. ✅ System triggers sponsor notification once\n\n**Integration:**\n1. ✅ IV1: Works with existing DocuSeal email system\n2. ✅ IV2: Enrollment correctly links to submissions created by TP\n3. ✅ IV3: Performance handles 500+ student cohorts\n\n**Security:**\n1. ✅ TP can only enroll students in their institution\'s cohorts\n2. ✅ Student access tokens expire after configurable duration (default 30 days)\n3. ✅ **Progress is saved independently of token expiration**\n4. ✅ **Expired tokens can be renewed via email verification**\n5. ✅ Upload tracking prevents unauthorized document completion\n6. ✅ Email validation prevents malformed addresses\n\n**Quality:**\n1. ✅ Bulk enrollment has progress feedback\n2. ✅ Duplicate email prevention\n3. ✅ Proper error messages for invalid data\n4. ✅ 85% test coverage",
|
|
},
|
|
{
|
|
number: "2.4",
|
|
title: "Sponsor Review Workflow",
|
|
user_story: "**As a** Sponsor,\n**I want** to review all student documents in my cohort and sign them in bulk,\n**So that** I can complete the verification workflow efficiently.",
|
|
background: "After all students complete their portion, the cohort enters \"ready_for_sponsor\" state. The sponsor:\n- Receives ONE email invitation (Story 2.2 ensures this)\n- Gets a portal view showing all students and their documents\n- Can review each student\'s completed document\n- Can sign/verify in bulk or individually\n- System tracks sponsor completion\n\n**No account creation needed** - sponsor uses ad-hoc token-based access.",
|
|
acceptance: "**Functional:**\n1. ✅ Sponsor receives single email invitation\n2. ✅ Sponsor can access portal via token link\n3. ✅ Sponsor sees all student submissions in list\n4. ✅ Sponsor can view each student\'s completed document\n5. ✅ Sponsor can verify/approve students individually or in bulk\n6. ✅ System tracks sponsor verification per student\n7. ✅ Cohort moves to TP review when sponsor completes\n\n**Integration:**\n1. ✅ IV1: Works with existing DocuSeal document viewing\n2. ✅ IV2: Sponsor tokens integrate with ad-hoc auth system\n3. ✅ IV3: Performance with 100+ students\n\n**Security:**\n1. ✅ Sponsor can only access their assigned cohort\n2. ✅ Sponsor access tokens expire after configurable duration (default 30 days)\n3. ✅ **Progress is saved independently of token expiration**\n4. ✅ **Expired tokens can be renewed via email verification**\n5. ✅ Cannot view other cohorts\' data\n6. ✅ Verification data is tamper-proof\n\n**Quality:**\n1. ✅ Clear UI feedback during verification\n2. ✅ Error handling for expired/invalid tokens\n3. ✅ Audit trail of sponsor actions\n4. ✅ 85% test coverage",
|
|
},
|
|
{
|
|
number: "2.5",
|
|
title: "TP Review & Finalization",
|
|
user_story: "**As a** TP administrator,\n**I want** to review the sponsor-verified submissions and finalize the cohort,\n**So that** the entire 3-party signature workflow is completed and documents are ready for archival.",
|
|
background: "Final phase of the workflow:\n1. Sponsor completes verification (Story 2.4)\n2. Cohort enters TP review state\n3. TP admin reviews sponsor\'s verification\n4. TP can approve/reject the cohort\n5. Cohort moves to completed state\n6. All documents finalized and archived\n\nThis is the final quality check in the workflow.",
|
|
acceptance: "**Functional:**\n1. ✅ TP sees sponsor verification dashboard\n2. ✅ TP can review all student verifications\n3. ✅ TP can approve/reject individual students\n4. ✅ TP can finalize entire cohort\n5. ✅ System archives all documents\n6. ✅ System generates completion report\n7. ✅ Cohort marked as completed\n8. ✅ Audit trail complete\n\n**Integration:**\n1. ✅ IV1: Uses existing DocuSeal document archiving\n2. ✅ IV2: Completes workflow state machine\n3. ✅ IV3: Handles large cohorts without performance issues\n\n**Security:**\n1. ✅ Only TP can access review dashboard\n2. ✅ All actions logged with user attribution\n3. ✅ Finalized documents cannot be modified\n4. ✅ Completion report is read-only\n\n**Quality:**\n1. ✅ Clear indication of verification status\n2. ✅ Errors for incomplete verification attempts\n3. ✅ Very fast finalization (< 3 seconds)\n4. ✅ 80% test coverage",
|
|
},
|
|
{
|
|
number: "2.6",
|
|
title: "Excel Export for Cohort Data",
|
|
user_story: "**As a** TP administrator,\n**I want** to export cohort enrollment data to Excel,\n**So that** I can perform additional analysis or reporting outside the system.",
|
|
background: "FR23 requires Excel export capability. This should include:\n- Student enrollment information\n- Document status (completed/incomplete)\n- Verification status (TP, students, sponsor)\n- Required upload status\n\nThis allows TP admins to use Excel for additional reporting.",
|
|
acceptance: "**Functional:**\n1. ✅ TP can export cohort to Excel (.xlsx format)\n2. ✅ Export includes all student enrollment data\n3. ✅ Export includes completion status\n4. ✅ Export includes sponsor verification status\n5. ✅ Export includes upload tracking\n6. ✅ Export includes summary statistics\n7. ✅ File downloads automatically\n\n**Integration:**\n1. ✅ IV1: Works with existing authorization\n2. ✅ IV2: Performance acceptable for 500 students\n3. ✅ IV3: No memory leaks with large exports\n\n**Security:**\n1. ✅ Only TP can export their institution\'s cohorts\n2. ✅ Export contains no sensitive tokens/PII\n3. ✅ File cleaned up after download\n\n**Quality:**\n1. ✅ Clean Excel formatting\n2. ✅ Handle special characters in names\n3. ✅ Nice error message for empty cohorts\n4. ✅ 80% test coverage",
|
|
},
|
|
{
|
|
number: "2.7",
|
|
title: "Audit Log & Compliance",
|
|
user_story: "**As a** TP administrator,\n**I want** comprehensive audit logs of all cohort workflow activities,\n**So that** we can demonstrate compliance and trace any issues.",
|
|
background: "FloDoc handles sensitive training documents. Compliance requires:\n- Immutable audit trail of all actions\n- Who did what and when\n- Document access tracking\n- Workflow state changes\n- Sponsor access tracking\n\nAll audit logs must be tamper-proof and easily searchable.",
|
|
acceptance: "**Functional:**\n1. ✅ Every cohort action is logged\n2. ✅ All logs are immutable (no updates/deletes)\n3. ✅ System actions logged even without user\n4. ✅ Document access tracking works\n5. ✅ Audit reports can be generated\n6. ✅ Reports show workflow timeline\n7. ✅ Reports filter by date range\n8. ✅ Reports show event counts and breakdowns\n\n**Integration:**\n1. ✅ IV1: Audit calls work without blocking main operations\n2. ✅ IV2: Logs integrate with existing models\n3. ✅ IV3: Performance impact < 5% on operations\n\n**Security:**\n1. ✅ Audit logs protected from tampering\n2. ✅ Only admins can view audit reports\n3. ✅ Logs don\'t contain sensitive data (passwords, tokens)\n4. ✅ Immutable storage is enforced\n\n**Quality:**\n1. ✅ Standardized log format\n2. ✅ Comprehensive coverage (all actions)\n3. ✅ Clear error handling if audit logging fails\n4. ✅ 90% test coverage for audit module",
|
|
},
|
|
{
|
|
number: "2.8",
|
|
title: "Cohort State Machine & Workflow Orchestration",
|
|
user_story: "**As a** system,\n**I want** to manage cohort state transitions and workflow enforcement,\n**So that** the 3-party signature workflow follows the correct sequence and prevents invalid operations.",
|
|
background: "The FloDoc workflow has strict state requirements:\n1. **Draft** → TP signs first document\n2. **TP Signing** → Student enrollment\n3. **Student Enrollment** → Student completion\n4. **Ready for Sponsor** → Sponsor review\n5. **Sponsor Review** → TP verification\n6. **TP Review** → Completed\n\nCannot skip steps. Prevents chaos.\n\nThis story ties together all Phase 2 logic with proper state enforcement.",
|
|
acceptance: "**Functional:**\n1. ✅ State transitions work via AASM events\n2. ✅ Guards prevent invalid transitions\n3. ✅ All workflow steps enforced\n4. ✅ Cohort cannot skip steps\n5. ✅ Workflow validations provide clear errors\n6. ✅ System prevents operations in wrong states\n7. ✅ Background job detects stuck cohorts\n\n**Integration:**\n1. ✅ IV1: State machine works with existing services\n2. ✅ IV2: Audit logs all state changes\n3. ✅ IV3: No impact on performance\n\n**Security:**\n1. ✅ Guards prevent unauthorized bypassing\n2. ✅ State changes logged\n3. ✅ Cannot manually set arbitrary states\n\n**Quality:**\n1. ✅ Clear error messages for failed transitions\n2. ✅ State validation in errors\n3. ✅ 85% test coverage for state machine",
|
|
},
|
|
{
|
|
number: "3.1",
|
|
title: "RESTful Cohort Management API",
|
|
user_story: "**As a** TP administrator or external system integrator,\n**I want** to create, read, update, and delete cohorts via REST API,\n**So that** I can automate cohort management and integrate with other systems.",
|
|
background: "The FloDoc system needs a complete REST API for cohort management. This API will be used by:\n\n1. **TP Portal** (Vue.js frontend) - All cohort operations\n2. **External systems** - Programmatic cohort creation and management\n3. **Automation scripts** - Bulk operations and integrations\n\nThe API should follow JSON:API standards and include proper authentication/authorization.",
|
|
acceptance: "**Functional:**\n1. ✅ GET /api/v1/cohorts - List cohorts with pagination\n2. ✅ POST /api/v1/cohorts - Create cohort\n3. ✅ GET /api/v1/cohorts/:id - Show cohort details\n4. ✅ PUT /api/v1/cohorts/:id - Update cohort\n5. ✅ DELETE /api/v1/cohorts/:id - Delete cohort (soft)\n6. ✅ POST /api/v1/cohorts/:id/start_signing - Start TP signing phase\n7. ✅ POST /api/v1/cohorts/:id/enroll_students - Bulk enroll students\n8. ✅ POST /api/v1/cohorts/:id/send_invites - Send student invitations\n9. ✅ GET /api/v1/cohorts/:id/status - Get cohort status\n10. ✅ GET /api/v1/cohorts/:id/export - Export to Excel\n11. ✅ GET /api/v1/sponsor/:token/dashboard - Sponsor dashboard\n12. ✅ POST /api/v1/sponsor/:token/verify/:student_id - Sponsor verification\n\n**Integration:**\n1. ✅ IV1: All endpoints use existing service objects\n2. ✅ IV2: Authorization works through CancanCan\n3. ✅ IV3: API response time < 500ms for standard queries\n\n**Security:**\n1. ✅ Authenticated access for TP endpoints\n2. ✅ Token validation for sponsor endpoints\n3. ✅ Authorization checks on all operations\n4. ✅ No sensitive data leaked in responses\n5. ✅ Rate limiting (if applicable)\n\n**Quality:**\n1. ✅ Consistent response format across all endpoints\n2. ✅ Proper HTTP status codes\n3. ✅ Standardized error messages\n4. ✅ API documentation in code comments\n5. ✅ 85% test coverage",
|
|
},
|
|
{
|
|
number: "3.2",
|
|
title: "Webhook Events for Workflow State Changes",
|
|
user_story: "**As a** TP administrator,\n**I want** webhook notifications for all cohort workflow events,\n**So that** external systems can react to state changes in real-time.",
|
|
background: "FloDoc should emit webhooks for:\n- Cohort created\n- TP signing completed\n- Student enrolled\n- Student completed\n- Sponsor accessed portal\n- Sponsor verified student\n- Cohort completed\n\nThis allows external integrations (e.g., CRM, LMS, reporting systems) to stay in sync.",
|
|
acceptance: "**Functional:**\n1. ✅ Webhook events created for all 7 event types\n2. ✅ Events queued for background delivery\n3. ✅ Signature generation works correctly\n4. ✅ Retry logic handles failures\n5. ✅ Multiple webhook URLs supported\n6. ✅ Event status tracking (pending/delivered/failed)\n7. ✅ Payload includes all relevant data\n\n**Integration:**\n1. ✅ IV1: Events emitted at correct workflow points\n2. ✅ IV2: Delivery job executes successfully\n3. ✅ IV3: No impact on main workflow performance\n\n**Security:**\n1. ✅ Signatures prevent tampering\n2. ✅ HTTPS URLs only (validation)\n3. ✅ Secrets can be customized per cohort\n4. ✅ Failed deliveries don\'t expose sensitive data\n\n**Quality:**\n1. ✅ Clear event naming convention\n2. ✅ Comprehensive audit logging\n3. ✅ Error messages for debugging\n4. ✅ 85% test coverage",
|
|
},
|
|
{
|
|
number: "3.3",
|
|
title: "Student API (Ad-hoc Token-Based Access)",
|
|
user_story: "**As a** student with a cohort link,\n**I want** a simple token-based API to access and complete my documents,\n**So that** I can fulfill my requirements without account creation.",
|
|
background: "Students need to:\n- Access their pre-filled document\n- Fill in their personal fields\n- Upload required documents\n- Submit the final document\n- All without creating an account\n\nThis requires a secure token-based API that:\n- Validates tokens against cohort and email\n- Exposes only student\'s own document\n- Tracks completion status",
|
|
acceptance: "**Functional:**\n1. ✅ GET /api/v1/students/:token/status - Check progress\n2. ✅ GET /api/v1/students/:token - Show document with pre-filled data\n3. ✅ PUT /api/v1/students/:token - Save student field values\n4. ✅ POST /api/v1/students/:token/upload - Upload required documents\n5. ✅ POST /api/v1/students/:token/submit - Submit final document\n6. ✅ Students cannot edit TP\'s pre-filled fields\n7. ✅ Progress tracking shows completion percentage\n\n**Integration:**\n1. ✅ IV1: Works with existing DocuSeal document rendering\n2. ✅ IV2: Student tokens integrate with ad-hoc auth system\n3. ✅ IV3: No impact on existing submission workflow\n\n**Security:**\n1. ✅ Students can only access their own enrollment\n2. ✅ Tokens have 30-day expiration\n3. ✅ Cannot access other students in cohort\n4. ✅ CSRF protection (if needed)\n\n**Quality:**\n1. ✅ Clear error messages\n2. ✅ Nice UI data structure\n3. ✅ Proper validation\n4. ✅ 85% test coverage",
|
|
},
|
|
{
|
|
number: "3.4",
|
|
title: "API Documentation & Versioning",
|
|
user_story: "**As a** developer integrating with FloDoc,\n**I want** comprehensive API documentation and stable versioning,\n**So that** I can build reliable integrations without breaking changes.",
|
|
background: "API documentation must include:\n- Endpoint reference\n- Request/response examples\n- Authentication methods\n- Error codes\n- Rate limits\n- Versioning strategy\n\nThis will be the source of truth for both internal frontend and external integrations.",
|
|
acceptance: "**Functional:**\n1. ✅ OpenAPI/Swagger spec for all endpoints\n2. ✅ Static documentation in /docs/api\n3. ✅ Versioning strategy documented\n4. ✅ Authentication methods documented (JWT + ad-hoc tokens)\n5. ✅ Error response format documented with all error codes\n6. ✅ Rate limiting implemented and documented (100 req/min)\n7. ✅ Code examples provided for all 6 core endpoints\n8. ✅ Change log maintained\n9. ✅ Complete request/response examples for POST /cohorts\n10. ✅ Complete request/response examples for GET /cohorts\n11. ✅ Complete request/response examples for POST /cohorts/{id}/start_signing\n12. ✅ Complete request/response examples for GET /sponsor/{token}/dashboard\n13. ✅ Complete request/response examples for POST /students/{token}/submit\n14. ✅ Complete request/response examples for POST /webhooks\n15. ✅ All error scenarios documented (400, 401, 403, 404, 422, 429, 500)\n\n**Quality:**\n1. ✅ Documentation is comprehensive\n2. ✅ Examples are runnable/verifiable\n3. ✅ Coverage of all 11+ endpoints\n4. ✅ Clear migration path for API versions\n5. ✅ All HTTP status codes documented\n6. ✅ All request headers documented\n7. ✅ All response fields explained\n8. ✅ Ad-hoc token flow clearly documented\n\n**Integration:**\n1. ✅ IV1: Documentation matches actual implementation\n2. ✅ IV2: Examples work without modification\n3. ✅ IV3: Static docs don\'t affect app performance\n4. ✅ IV4: All documented endpoints exist in routes",
|
|
},
|
|
{
|
|
number: "4.1",
|
|
title: "Cohort Management Dashboard",
|
|
user_story: "**As a** TP administrator,\n**I want** a dashboard to view and manage all cohorts,\n**So that** I can monitor the 3-party workflow at a glance.",
|
|
background: "TP Portal needs a comprehensive dashboard showing:\n- Cohort list with status and progress\n- Quick actions (create, open, export)\n- Filter and search capability\n- High-level metrics (total cohorts, active, completed)\n- Recent activity feed\n\nThis is the main entry point for TP administrators.",
|
|
acceptance: "**Functional:**\n1. ✅ Dashboard displays cohort list with pagination\n2. ✅ Metrics cards show accurate statistics\n3. ✅ Filters work (status, program type, search)\n4. ✅ Status badges display correctly\n5. ✅ Progress bars show student completion\n6. ✅ Actions (open/edit/export) work\n7. ✅ Empty state displays when no cohorts\n8. ✅ Pagination works\n\n**Integration:**\n1. ✅ IV1: API calls use correct endpoints\n2. ✅ IV2: Pinia store manages state properly\n3. ✅ IV3: Components follow design system\n\n**Security:**\n1. ✅ Only authenticated TP users can access\n2. ✅ Users only see their institution\'s cohorts\n3. ✅ Export button calls correct authorization\n\n**Quality:**\n1. ✅ Follows Vue 3 best practices\n2. ✅ Components are reusable\n3. ✅ TypeScript types defined\n4. ✅ Design system compliance\n5. ✅ 80% test coverage",
|
|
},
|
|
{
|
|
number: "4.2",
|
|
title: "Cohort Creation & Bulk Import",
|
|
user_story: "**As a** TP administrator,\n**I want** to create new cohorts and bulk-import students via Excel,\n**So that** I can efficiently onboard large groups without manual data entry.",
|
|
background: "The cohort creation process needs to support:\n- Basic cohort information (name, dates, description)\n- Optional bulk student import via Excel spreadsheet\n- Validation and preview before committing data\n- Seamless navigation to cohort detail after creation\n\nThis enables TP administrators to quickly set up new training cohorts with minimal effort.",
|
|
acceptance: "**Functional:**\n1. ✅ Form validation prevents submission with missing required fields\n2. ✅ Date pickers work correctly and prevent invalid date ranges\n3. ✅ Excel upload accepts only .xlsx files\n4. ✅ Validation shows preview of first 5 students\n5. ✅ Validation counts total student count\n6. ✅ Validation identifies formatting errors (missing emails, duplicates)\n7. ✅ User can re-upload file if validation fails\n8. ✅ Create button disabled until form is valid\n9. ✅ Success notification on cohort creation\n10. ✅ Auto-navigate to cohort detail after creation\n11. ✅ Bulk import creates student records with pending status\n12. ✅ Cohort name uniqueness enforced (optional, backend)\n\n**UI/UX:**\n1. ✅ Follows design system colors and spacing\n2. ✅ Upload zone has clear drag-and-drop visual feedback\n3. ✅ Loading states display during upload and creation\n4. ✅ Error messages are clear and actionable\n5. ✅ Preview table is scrollable if many rows\n6. ✅ Form is responsive on mobile devices\n7. ✅ All buttons have proper hover states\n8. ✅ File input is accessible (keyboard navigation)\n\n**Integration:**\n1. ✅ IV1: API calls use correct endpoints\n2. ✅ IV2: Pinia store updates after creation\n3. ✅ IV3: Error handling works for network failures\n4. ✅ IV4: Excel validation endpoint returns correct data structure\n\n**Security:**\n1. ✅ Only authenticated TP users can access\n2. ✅ File upload size limit enforced (10MB max)\n3. ✅ File type validation on client and server\n4. ✅ Sanitization of cohort names and descriptions\n5. ✅ Rate limiting on create endpoint\n\n**Quality:**\n1. ✅ Follows Vue 3 best practices\n2. ✅ TypeScript types defined for all data\n3. ✅ Components are reusable (form fields extracted)\n4. ✅ 80% test coverage\n5. ✅ Design system compliance verified",
|
|
},
|
|
{
|
|
number: "4.3",
|
|
title: "Cohort Detail Overview",
|
|
user_story: "**As a** TP administrator,\n**I want** to view detailed information about a specific cohort, including student list, progress status, and document workflow,\n**So that** I can monitor and manage the cohort effectively.",
|
|
background: "After creating a cohort, administrators need a comprehensive view to:\n- See all students and their current status\n- Monitor workflow progression through the 4 stages\n- View cohort metadata and settings\n- Access quick actions based on current workflow stage\n- Filter and search students\n\nThis view serves as the central hub for cohort management.",
|
|
acceptance: "**Functional:**\n1. ✅ Loads cohort details on page visit\n2. ✅ Displays all cohort information correctly\n3. ✅ Shows 5 stat cards with correct values\n4. ✅ Renders workflow steps with correct active state\n5. ✅ Lists all students in the cohort\n6. ✅ Filters students by status (all/pending/in_progress/completed)\n7. ✅ Searches students by name or email\n8. ✅ Shows status counts that update with filters\n9. ✅ Displays empty state when no students match filters\n10. ✅ Each student row has \"View\" button\n11. ✅ \"View\" button navigates to student detail\n12. ✅ \"Start Signing\" button navigates to signing interface\n13. ✅ \"Export Data\" button triggers export (links to Story 4.8)\n14. ✅ Quick action buttons are disabled when not applicable\n15. ✅ Shows \"Not found\" when cohort doesn\'t exist\n\n**UI/UX:**\n1. ✅ Follows design system colors and spacing\n2. ✅ Responsive layout on mobile devices\n3. ✅ Loading state displays during data fetch\n4. ✅ Status badges use correct colors\n5. ✅ Workflow steps are visually distinct\n6. ✅ Tables are scrollable on small screens\n7. ✅ All interactive elements have hover states\n8. ✅ Empty states are helpful and clear\n\n**Integration:**\n1. ✅ IV1: API calls use correct endpoints\n2. ✅ IV2: Pinia stores manage state correctly\n3. ✅ IV3: Router navigation works\n4. ✅ IV4: Data flows between components correctly\n\n**Security:**\n1. ✅ Only authenticated TP users can access\n2. ✅ Users only see their institution\'s cohorts\n3. ✅ Student data is not exposed to unauthorized users\n4. ✅ All API endpoints require proper authorization\n\n**Quality:**\n1. ✅ Follows Vue 3 best practices\n2. ✅ TypeScript types defined\n3. ✅ Components are maintainable\n4. ✅ 80% test coverage\n5. ✅ Design system compliance verified",
|
|
},
|
|
{
|
|
number: "4.4",
|
|
title: "TP Signing Interface",
|
|
user_story: "**As a** TP administrator,\n**I want** to sign the first student\'s document and have it automatically replicated to all other students,\n**So that** I can sign once instead of signing each student\'s document individually.",
|
|
background: "The TP Signing Phase is the critical first step in the 3-party workflow. Key requirements:\n- TP signs ONE document (the first student\'s document)\n- System duplicates the signed submission to all other students\n- TP\'s fields and signatures are pre-filled across all student submissions\n- This eliminates duplicate signing work for the TP\n- Prevents duplicate sponsor emails through workflow state management\n\nThis is the core innovation of FloDoc - bulk signing capability.",
|
|
acceptance: "**Functional:**\n1. ✅ Loads cohort and form fields on page visit\n2. ✅ Displays correct student count\n3. ✅ Shows workflow reminder with correct current step\n4. ✅ Renders all form fields based on template\n5. ✅ Accepts input for text fields\n6. ✅ Accepts input for textarea fields\n7. ✅ Accepts date selection\n8. ✅ Opens signature pad modal when clicking sign button\n9. ✅ Allows drawing signature on canvas\n10. ✅ Clears signature canvas\n11. ✅ Saves signature as image data\n12. ✅ Displays signature preview\n13. ✅ Allows removing signature\n14. ✅ Handles checkbox fields\n15. ✅ Validates all required fields before signing\n16. ✅ Shows validation errors\n17. ✅ Preview button shows field values\n18. ✅ Sign & Replicate button disabled until valid\n19. ✅ Success state shows after signing\n20. ✅ Replicates to correct number of students\n21. ✅ \"Send Invitations\" button works\n22. ✅ Navigation back to cohort works\n\n**UI/UX:**\n1. ✅ Follows design system colors and spacing\n2. ✅ Responsive layout on mobile devices\n3. ✅ Loading states during operations\n4. ✅ Modal overlays work correctly\n5. ✅ Canvas drawing is smooth\n6. ✅ Error messages are clear\n7. ✅ Success state is visually distinct\n8. ✅ Progress bar shows signing progress\n9. ✅ All buttons have proper hover states\n10. ✅ Empty states handled gracefully\n\n**Integration:**\n1. ✅ IV1: API calls use correct endpoints\n2. ✅ IV2: Pinia store manages state correctly\n3. ✅ IV3: Router navigation works\n4. ✅ IV4: Data flows between components correctly\n\n**Security:**\n1. ✅ Only authenticated TP users can access\n2. ✅ Users can only sign their institution\'s cohorts\n3. ✅ Signature data is securely stored\n4. ✅ All API endpoints require proper authorization\n5. ✅ Rate limiting on signing endpoint\n\n**Quality:**\n1. ✅ Follows Vue 3 best practices\n2. ✅ TypeScript types defined\n3. ✅ Components are maintainable\n4. ✅ Canvas drawing uses efficient rendering\n5. ✅ 80% test coverage\n6. ✅ Design system compliance verified",
|
|
},
|
|
{
|
|
number: "4.5",
|
|
title: "Student Management View",
|
|
user_story: "**As a** TP administrator,\n**I want** to view and manage individual student details, including their document status and uploaded files,\n**So that** I can track student progress and troubleshoot issues.",
|
|
background: "After TP signing and student enrollment, administrators need granular visibility into each student\'s progress:\n- View student\'s personal information\n- See document status (pending/in_progress/completed)\n- Access uploaded required documents\n- Monitor student\'s field completion\n- Send reminders or reset student progress\n\nThis provides detailed cohort management capabilities.",
|
|
acceptance: "**Functional:**\n1. ✅ Loads student details on page visit\n2. ✅ Displays student name and email\n3. ✅ Shows status banner with correct state\n4. ✅ Status banner shows correct icon\n5. ✅ Status banner shows correct title\n6. ✅ Status banner shows correct description\n7. ✅ Shows completion timestamp if completed\n8. ✅ \"Send Reminder\" button works\n9. ✅ \"Send Reminder\" disabled for completed students\n10. ✅ \"Reset Progress\" button works\n11. ✅ \"Reset Progress\" disabled for pending students\n12. ✅ \"Copy Invite Link\" button works\n13. ✅ Invite link copied to clipboard\n14. ✅ Document status shows correct progress tracker\n15. ✅ Required uploads list shows all items\n16. ✅ Upload status shows uploaded/pending correctly\n17. ✅ \"View\" button for uploaded files works\n18. ✅ \"Remind\" button for pending uploads works\n19. ✅ Field values display correctly\n20. ✅ Empty state when no fields filled\n21. ✅ Student info grid shows all data\n22. ✅ Audit log displays events chronologically\n23. ✅ Empty state when no audit events\n24. ✅ \"Not found\" state for invalid student\n25. ✅ Confirmation modal for destructive actions\n26. ✅ Modal cancels correctly\n27. ✅ Modal confirms correctly\n\n**UI/UX:**\n1. ✅ Follows design system colors and spacing\n2. ✅ Responsive layout on mobile devices\n3. ✅ Loading state displays during data fetch\n4. ✅ Status banners use correct color coding\n5. ✅ Progress tracker is visually clear\n6. ✅ Timeline is visually distinct\n7. ✅ All buttons have proper hover states\n8. ✅ Empty states are helpful and clear\n9. ✅ Modal overlays work correctly\n10. ✅ Copy confirmation feedback shown\n\n**Integration:**\n1. ✅ IV1: API calls use correct endpoints\n2. ✅ IV2: Pinia store manages state correctly\n3. ✅ IV3: Router navigation works\n4. ✅ IV4: Clipboard API works for copy\n\n**Security:**\n1. ✅ Only authenticated TP users can access\n2. ✅ Users can only view their institution\'s students\n3. ✅ Sensitive data properly protected\n4. ✅ All API endpoints require proper authorization\n5. ✅ Invite links are token-based and secure\n\n**Quality:**\n1. ✅ Follows Vue 3 best practices\n2. ✅ TypeScript types defined\n3. ✅ Components are maintainable\n4. ✅ 80% test coverage\n5. ✅ Design system compliance verified",
|
|
},
|
|
{
|
|
number: "4.6",
|
|
title: "Sponsor Portal Dashboard",
|
|
user_story: "**As a** Sponsor,\n**I want** to access a dedicated portal where I can review and verify all student documents for a cohort,\n**So that** I can sign once for the entire cohort instead of signing each student individually.",
|
|
background: "The Sponsor Portal is a critical component of the 3-party workflow. Key requirements:\n- Sponsor receives ONE email with a single access link\n- Portal shows all students in two tabs based on sponsor\'s signing status:\n - **Pending Tab**: Students awaiting sponsor signature (before sponsor completes)\n - **Completed Tab**: Students where sponsor has already applied verification\n- Sponsor fills their fields once\n- System applies sponsor\'s signature to all student documents\n- After sponsor signs once, all students move to the Completed tab\n- Progress bar shows completion status\n\nThis is the second signing phase and requires careful state management.",
|
|
acceptance: "**Functional:**\n1. ✅ Loads cohort data using token from URL\n2. ✅ Displays cohort name and institution\n3. ✅ Shows progress bar with correct percentage\n4. ✅ Displays student counts (pending/completed)\n5. ✅ Tab navigation switches between pending/completed\n6. ✅ Pending tab shows all pending students\n7. ✅ Completed tab shows all completed students\n8. ✅ Student cards display name, email, ID\n9. ✅ Empty states show when no students in tab\n10. ✅ Sponsor form has all required fields\n11. ✅ Form validation prevents submission if incomplete\n12. ✅ Signature pad opens when clicking sign button\n13. ✅ Signature can be drawn on canvas\n14. ✅ Signature can be cleared\n15. ✅ Signature can be saved\n16. ✅ Signature preview shows saved signature\n17. ✅ \"Remove & Redraw\" works\n18. ✅ Checkbox consent works\n19. ✅ Preview button shows all fields\n20. ✅ Sign & Apply button disabled until valid\n21. ✅ Success state shows after signing\n22. ✅ Refresh button updates student list\n23. ✅ Invalid token shows error state\n\n**UI/UX:**\n1. ✅ Follows design system colors and spacing\n2. ✅ Responsive layout on mobile devices\n3. ✅ Loading state displays during data fetch\n4. ✅ Progress bar is visually clear\n5. ✅ Tab navigation is intuitive\n6. ✅ Student cards are visually distinct\n7. ✅ Modal overlays work correctly\n8. ✅ Canvas drawing is smooth\n9. ✅ Error messages are clear\n10. ✅ Success state is visually distinct\n\n**Integration:**\n1. ✅ IV1: API calls use correct endpoints with token auth\n2. ✅ IV2: Pinia store manages state correctly\n3. ✅ IV3: Getters calculate counts correctly\n4. ✅ IV4: Token-based routing works\n\n**Security:**\n1. ✅ Token-based authentication required\n2. ✅ Token expires after use or time limit\n3. ✅ Sponsor can only access assigned cohort\n4. ✅ All API endpoints require valid token\n5. ✅ Signature data is securely stored\n\n**Quality:**\n1. ✅ Follows Vue 3 best practices\n2. ✅ TypeScript types defined\n3. ✅ Components are maintainable\n4. ✅ 80% test coverage\n5. ✅ Design system compliance verified",
|
|
},
|
|
{
|
|
number: "4.7",
|
|
title: "Sponsor Portal - Bulk Document Signing",
|
|
user_story: "**As a** Sponsor,\n**I want** to sign once and have that signature applied to all pending student documents,\n**So that** I don\'t need to manually sign each student\'s documents individually.",
|
|
background: "In the previous story, sponsors gain access to a dashboard that tracks student completion status (Waiting → In Progress). Once all students have completed their part (uploaded required documents + completed their fields), the sponsor receives the bulk signing prompt.\n\nThe current DocuSeal limitation is that each submission requires independent signing, which creates unnecessary friction when the same sponsor is signing the same document type for multiple students in the same cohort. The sponsor portal must enable a bulk signing workflow where:\n\n1. Sponsor reviews the general cohort document structure\n2. Sponsor provides their signature once\n3. System atomically applies this signature to ALL 20+ student submissions\n4. System transitions cohort state to \"Completed - Signed\"\n5. Single sponsor email notification (not one per student)\n\nThis aligns with FR10 (Bulk Signing) and FR13 (Single Email Rule).",
|
|
acceptance: "**Functional:**\n1. ✅ Sponsor can only access bulk signing when all students are in \"completed_student\" status\n2. ✅ Signature can be provided via canvas (draw) or text input (typed)\n3. ✅ Preview shows signature applied to sample document before final signing\n4. ✅ Bulk sign button is disabled until canvas has data + confirmation checkbox is checked\n5. ✅ Clicking \"Sign All\" atomically applies signature to all pending submissions\n6. ✅ System transitions cohort from \"ready_for_sponsor\" to \"completed_sponsor\"\n7. ✅ After signing, sponsor is redirected to sponsor dashboard with success message\n8. ✅ All signed documents show in \"completed\" tab\n\n**UI/UX:**\n1. ✅ Modal-based interface with clear progress indicators\n2. ✅ Privacy notice about bulk signing action and irreversibility\n3. ✅ Student list shows pending vs completed with counts\n4. ✅ Canvas with clear/clear & type fallback options\n5. ✅ Signature preview generation within 2 seconds\n6. ✅ Loading states during preview generation and signing\n7. ✅ Error messages displayed in red with actionable retry options\n8. ✅ Mobile-responsive design (signature canvas scales)\n\n**Integration:**\n1. ✅ API endpoints: `GET /api/sponsor/cohorts/{id}/bulk-sign` and `POST /api/sponsor/submissions/bulk-sign`\n2. ✅ Token authentication in headers for all requests\n3. ✅ Cohort state machine updates to `completed_sponsor`\n4. ✅ Single email notification to training provider on completion\n5. ✅ Final documents stored in DocuSeal with sponsor signature\n\n**Security:**\n1. ✅ Token-based authentication with expiration handling\n2. ✅ Authorization check: sponsor can only sign their assigned cohort\n3. ✅ Signature data validated (not empty) before processing\n4. ✅ Rate limiting: maximum 5 bulk signing attempts per hour per token\n5. ✅ Audit log entry created for each bulk signing action\n\n**Quality:**\n1. ✅ Atomic transaction: all documents signed or none\n2. ✅ Performance: handles 50+ students with sub-5-second response\n3. ✅ Error handling: email to TP admin if bulk signing fails\n4. ✅ Canonical signature application (same signature instance across all)",
|
|
},
|
|
{
|
|
number: "4.8",
|
|
title: "Sponsor Portal - Progress Tracking & State Management",
|
|
user_story: "**As a** Sponsor,\n**I want** to see real-time progress tracking with clear visual indicators of which students have completed their documents and which are still pending,\n**So that** I can monitor the signing workflow and know exactly when to proceed with bulk signing.",
|
|
background: "After students complete their required actions (uploading documents, filling their fields), the sponsor needs visibility into the overall cohort progress. The sponsor portal dashboard must provide:\n\n1. **Progress Overview**: Visual progress bar showing percentage of students who have completed their part\n2. **Student List with Status**: Clear indication of each student\'s current state (Waiting → In Progress → Completed)\n3. **Document Preview**: Ability to view individual student documents before signing\n4. **State-Driven UI**: Interface elements that change based on cohort state:\n - \"Waiting for students\" - Sponsor cannot sign yet\n - \"Ready for bulk signing\" - All students completed, show bulk sign button\n - \"Completed\" - All documents signed, show completion status\n\nThis story implements the dashboard UI that was outlined in Story 4.6, providing the visual layer for progress tracking that the sponsor interacts with before bulk signing (Story 4.7).\n\nThe state management ensures sponsors don\'t attempt to sign prematurely and provides confidence that all students have completed their required actions.",
|
|
acceptance: "**Functional:**\n1. ✅ Dashboard loads cohort data on mount\n2. ✅ Progress bar calculates percentage correctly (completed / total * 100)\n3. ✅ Student list separates into Pending vs Completed tabs\n4. ✅ Pending tab shows students with status: waiting, in_progress, completed_student\n5. ✅ Completed tab shows students with status: completed_all\n6. ✅ Real-time polling updates data every 30 seconds\n7. ✅ \"Sign All Documents\" button only visible when cohort status is \'ready_for_sponsor\'\n8. ✅ Clicking \"Sign All\" opens Bulk Signing Modal (Story 4.7)\n9. ✅ Clicking \"View Document\" on completed student opens preview modal\n10. ✅ After bulk signing, dashboard refreshes and switches to Completed tab\n\n**UI/UX:**\n1. ✅ Progress bar animates smoothly (0.5s transition)\n2. ✅ Status badges use color-coded styling (yellow/blue/green)\n3. ✅ Student cards show avatar initials, name, email, and status\n4. ✅ Hover states on all interactive elements\n5. ✅ Empty states for both tabs (no students message)\n6. ✅ Loading state shown during initial fetch\n7. ✅ Error messages displayed prominently with retry option\n8. ✅ Mobile-responsive layout (stacks properly on small screens)\n9. ✅ Tab switching is instant and smooth\n10. ✅ Timestamps formatted human-readable (e.g., \"Jan 15, 2025\")\n\n**Integration:**\n1. ✅ API endpoint: `GET /api/sponsor/cohorts/{id}/progress`\n2. ✅ Token authentication in headers\n3. ✅ Polling mechanism uses `setInterval` with cleanup on unmount\n4. ✅ Store getters correctly filter students by status\n5. ✅ Modal components receive correct props (cohortId, token, student data)\n6. ✅ State updates propagate to child components\n\n**Security:**\n1. ✅ Token-based authentication required for all API calls\n2. ✅ Authorization check: sponsor can only view their assigned cohort\n3. ✅ Token validation on dashboard load\n4. ✅ No sensitive data (signatures, document contents) exposed in dashboard list\n5. ✅ Rate limiting on polling endpoint (max 1 request per 30 seconds)\n\n**Quality:**\n1. ✅ Polling stops when component unmounts (no memory leaks)\n2. ✅ Error boundaries handle API failures gracefully\n3. ✅ Data refreshes automatically without user intervention\n4. ✅ State consistency: UI always reflects latest data from server\n5. ✅ Performance: renders 50+ students without lag",
|
|
},
|
|
{
|
|
number: "4.9",
|
|
title: "Sponsor Portal - Token Renewal & Session Management",
|
|
user_story: "**As a** Sponsor,\n**I want** to renew my access token if it expires while I\'m reviewing documents,\n**So that** I can complete my signing workflow without losing progress or being locked out.",
|
|
background: "Sponsors access the portal via time-limited tokens sent by email (Story 2.4). These tokens expire after a configurable period (default 30 days, but often 24-48 hours for security). \n\nThe critical problem: A sponsor might:\n1. Open the portal and review 15 out of 20 student documents\n2. Take a break or get interrupted\n3. Return after token expiration to finish the remaining 5\n4. Discover they\'re locked out and must request a new token\n5. **Lose all progress** and have to start over\n\nThis creates a poor user experience and potential data loss. The solution requires:\n\n1. **Progress Persistence**: Save signing state independently of token\n2. **Pre-Expiration Warnings**: Email notification 2 hours before expiry\n3. **Renewal Mechanism**: One-click token renewal via email\n4. **Grace Period**: 5-minute buffer after expiration for active sessions\n5. **Session Management**: Clear indication of token status\n\nThis story implements the token renewal flow referenced in Stories 2.3 and 2.4, ensuring sponsors can complete their workflow even if they exceed the token lifetime.\n\n**Architecture Note**: This is the final story in Phase 4 (TP Portal - Frontend Development), completing the sponsor portal feature set.",
|
|
acceptance: "**Functional:**\n1. ✅ Banner appears when token enters warning period (<4 hours or <25% duration)\n2. ✅ Banner shows countdown timer updating in real-time\n3. ✅ \"Renew Token\" button sends renewal request to API\n4. ✅ Success message appears after renewal email sent\n5. ✅ Error message appears if renewal fails\n6. ✅ Modal appears immediately when token expires\n7. ✅ Modal offers \"Renew\" or \"Logout\" options\n8. ✅ Renewal count tracked (max 3 per cohort)\n9. ✅ Token state saved to localStorage\n10. ✅ State restored on page reload if still valid\n\n**UI/UX:**\n1. ✅ Banner color changes based on urgency (yellow → orange → red)\n2. ✅ Countdown format: \"2h 15m\" for >1h, \"45m 30s\" for <1h\n3. ✅ Banner dismissible (but reappears on next visit)\n4. ✅ Modal has clear messaging about expiration\n5. ✅ Loading states on renewal button\n6. ✅ Success/error messages auto-dismiss after 5 seconds\n7. ✅ Mobile-responsive banner and modal\n8. ✅ Visual distinction between warning and expired states\n\n**Integration:**\n1. ✅ API endpoint: `POST /api/sponsor/tokens/renew`\n2. ✅ Token validation on dashboard load\n3. ✅ Renewal email contains new token link\n4. ✅ New token auto-applies and reloads page\n5. ✅ Token store integrates with dashboard store\n6. ✅ Banner appears on all sponsor portal pages\n\n**Security:**\n1. ✅ Maximum 3 renewals per cohort (prevents abuse)\n2. ✅ Rate limiting on renewal endpoint (1 per minute)\n3. ✅ Audit log of all renewal attempts\n4. ✅ Token validation before allowing renewal\n5. ✅ New tokens have full 48-hour duration (not extended)\n6. ✅ Old tokens invalidated when new one issued\n\n**Quality:**\n1. ✅ State persists across browser sessions\n2. ✅ No memory leaks (intervals cleaned up)\n3. ✅ Handles edge cases (network errors, invalid tokens)\n4. ✅ Graceful degradation if localStorage unavailable\n5. ✅ Time calculations accurate across timezones",
|
|
},
|
|
{
|
|
number: "4.10",
|
|
title: "TP Portal - Cohort Status Monitoring & Analytics",
|
|
user_story: "**As a** Training Provider,\n**I want** to monitor all cohorts with real-time status updates and analytics,\n**So that** I can track progress, identify bottlenecks, and manage my document signing workflows efficiently.",
|
|
background: "After creating cohorts and initiating workflows, training providers need visibility into the entire system. The TP Portal dashboard must provide:\n\n1. **Cohort Overview**: List of all cohorts with key metrics\n2. **Real-time Status**: Live updates of student and sponsor progress\n3. **Analytics**: Completion rates, average time to completion, bottlenecks\n4. **Actionable Insights**: Which cohorts need attention, which are completed\n5. **Bulk Operations**: Manage multiple cohorts simultaneously\n\nThis is the final story in Phase 4, completing the TP Portal frontend development. It builds upon:\n- Story 4.1: TP Portal Dashboard Layout\n- Story 4.2: TP Signing Phase Logic\n- Story 4.3: TP Review Dashboard\n- Story 4.4: TP Portal - Cohort Creation Wizard\n- Story 4.5: TP Portal - Cohort Management & Student List\n- Story 4.6: Sponsor Portal Dashboard\n- Story 4.7: Sponsor Portal - Bulk Document Signing\n- Story 4.8: Sponsor Portal - Progress Tracking\n- Story 4.9: Sponsor Portal - Token Renewal\n\nThe TP monitoring dashboard is the command center for training providers, giving them complete visibility and control over their cohort workflows.",
|
|
acceptance: "**Functional:**\n1. ✅ Dashboard loads all cohorts on mount\n2. ✅ Analytics cards show correct totals and calculations\n3. ✅ Search filters cohorts by name or ID\n4. ✅ Status filter works correctly\n5. ✅ Sort by name, status, or creation date\n6. ✅ Real-time polling updates data every 30 seconds\n7. ✅ \"Refresh All\" button manually triggers update\n8. ✅ Clicking \"View\" opens cohort detail modal\n9. ✅ \"Send Reminder\" available for in-progress cohorts\n10. ✅ \"Export\" downloads Excel file for completed cohorts\n11. ✅ New cohort button opens creation wizard\n12. ✅ Progress bars animate smoothly\n13. ✅ Last updated timestamp shows relative time\n\n**UI/UX:**\n1. ✅ Desktop: Table layout with 7 columns\n2. ✅ Mobile: Card layout with stacked information\n3. ✅ Status badges use color-coded styling\n4. ✅ Progress bars change color based on percentage\n5. ✅ Hover states on all interactive rows\n6. ✅ Loading states during data fetch\n7. ✅ Empty state when no cohorts exist\n8. ✅ Live indicator shows polling status\n9. ✅ Time since last update displays correctly\n10. ✅ Responsive design works on all screen sizes\n\n**Integration:**\n1. ✅ API endpoints: `GET /api/tp/cohorts`, `GET /api/tp/cohorts/{id}`, `POST /api/tp/cohorts/{id}/remind`, `POST /api/tp/cohorts/{id}/export`\n2. ✅ Polling mechanism with cleanup on unmount\n3. ✅ Store getters calculate analytics correctly\n4. ✅ Modal components receive correct props\n5. ✅ Export triggers file download\n6. ✅ Reminder sends email notifications\n\n**Security:**\n1. ✅ All API calls require authentication (TP session)\n2. ✅ Authorization check: TP can only view their own cohorts\n3. ✅ Export endpoint rate limited (max 5 per hour)\n4. ✅ Reminder endpoint rate limited (max 10 per hour)\n5. ✅ No sensitive data exposed in list view\n\n**Quality:**\n1. ✅ Polling stops when component unmounts\n2. ✅ Error handling for failed API calls\n3. ✅ Data consistency across refreshes\n4. ✅ Performance: renders 100+ cohorts without lag\n5. ✅ No duplicate polling intervals",
|
|
},
|
|
{
|
|
number: "5.1",
|
|
title: "Student Portal - Document Upload Interface",
|
|
user_story: "**As a** Student,\n**I want** to upload required documents (ID, certificates, etc.) through a simple interface,\n**So that** I can provide the necessary proof documents for my cohort enrollment.",
|
|
background: "Students receive email invitations to join a cohort (Story 2.2). Upon clicking the link, they access the student portal where they must complete several steps:\n\n1. **Upload Required Documents**: Government ID, certificates, photos, etc.\n2. **Fill Assigned Fields**: Personal information, signatures, dates\n3. **Review & Submit**: Final confirmation before sponsor review\n\nThis story implements the document upload interface, which is the first step in the student workflow. The interface must:\n\n- Accept multiple file types (PDF, JPG, PNG)\n- Show upload progress\n- Validate file size and type\n- Allow preview of uploaded files\n- Support drag-and-drop\n- Work on mobile devices\n\nThe uploaded documents are stored in Active Storage and linked to the student\'s submission record. After upload, students proceed to fill their assigned fields (Story 5.2).\n\n**Integration Point**: This uploads documents that will be referenced in the final signed PDF generated by DocuSeal.",
|
|
acceptance: "**Functional:**\n1. ✅ Component loads and fetches document requirements on mount\n2. ✅ Displays list of required documents with descriptions\n3. ✅ Supports drag-and-drop file upload\n4. ✅ Supports click-to-upload file selection\n5. ✅ Validates file type against accepted types\n6. ✅ Validates file size against max size\n7. ✅ Shows upload progress bar during upload\n8. ✅ Displays uploaded files with name and size\n9. ✅ Allows preview of uploaded files\n10. ✅ Allows removal of uploaded files\n11. ✅ Shows error messages for validation failures\n12. ✅ Save Draft button saves progress without validation\n13. ✅ Continue button only enabled when all required files uploaded\n14. ✅ Progress bar updates correctly based on uploaded count\n\n**UI/UX:**\n1. ✅ Drag-and-drop shows visual feedback (border color change, background)\n2. ✅ Upload progress animates smoothly\n3. ✅ Success state shows green checkmark and background\n4. ✅ Error messages appear in red below upload area\n5. ✅ File preview shows appropriate icon (image vs document)\n6. ✅ File size formatted human-readable (KB, MB)\n7. ✅ Mobile-responsive design (stacks properly on small screens)\n8. ✅ Loading state during initial requirements fetch\n9. ✅ Empty state when no requirements exist\n10. ✅ Confirmation dialog before file removal\n\n**Integration:**\n1. ✅ API endpoint: `GET /api/student/submissions/{id}/requirements`\n2. ✅ API endpoint: `POST /api/student/submissions/{id}/documents` (with progress)\n3. ✅ API endpoint: `DELETE /api/student/submissions/{id}/documents/{req_id}`\n4. ✅ API endpoint: `POST /api/student/submissions/{id}/draft`\n5. ✅ API endpoint: `POST /api/student/submissions/{id}/complete-upload`\n6. ✅ Token authentication in headers\n7. ✅ Progress tracking via XMLHttpRequest upload events\n8. ✅ State persistence in Pinia store\n\n**Security:**\n1. ✅ Token-based authentication required\n2. ✅ Authorization check: student can only upload to their submission\n3. ✅ File type validation (server-side + client-side)\n4. ✅ File size validation (server-side + client-side)\n5. ✅ No executable file types allowed\n6. ✅ Rate limiting on upload endpoint (max 10 uploads per hour)\n7. ✅ Virus scanning on server (documented requirement)\n\n**Quality:**\n1. ✅ Uploads are atomic (all or nothing)\n2. ✅ Network errors handled gracefully with retry option\n3. ✅ No memory leaks (clean up file objects)\n4. ✅ Performance: handles files up to 50MB\n5. ✅ Browser compatibility: Chrome, Firefox, Safari, Edge",
|
|
},
|
|
{
|
|
number: "5.2",
|
|
title: "Student Portal - Form Filling & Field Completion",
|
|
user_story: "**As a** Student,\n**I want** to fill in my assigned form fields (personal info, signatures, dates, etc.),\n**So that** I can complete my portion of the document before the sponsor signs.",
|
|
background: "After uploading required documents (Story 5.1), students must fill their assigned fields in the document. This is the core of the student workflow where they provide:\n\n1. **Personal Information**: Name, address, contact details\n2. **Signatures**: Digital signature capture\n3. **Dates**: Date pickers for various fields\n4. **Checkboxes**: Agreements and confirmations\n5. **Text Fields**: Additional information or comments\n\nThe form builder (created by TP in Story 4.4) defines which fields each student must fill. This story implements the rendering and completion of those fields.\n\n**Key Requirements:**\n- Fields are pre-defined by TP in the template\n- Each student sees only their assigned fields\n- Signature can be drawn or typed\n- All fields must be valid before submission\n- Progress is auto-saved\n- Mobile-friendly input methods\n\n**Integration Point**: Field data is merged with uploaded documents and TP\'s signature to generate the final PDF in DocuSeal.",
|
|
acceptance: "**Functional:**\n1. ✅ Component loads and fetches form fields on mount\n2. ✅ Renders all field types correctly (text, email, date, number, checkbox, radio, select, signature, textarea)\n3. ✅ Validates each field type appropriately\n4. ✅ Shows error messages below invalid fields\n5. ✅ Signature canvas supports drawing with mouse/touch\n6. ✅ Signature can be cleared and replaced with text\n7. ✅ Progress bar updates as fields are completed\n8. ✅ Auto-save triggers every 30 seconds if changes detected\n9. ✅ Save Draft button works immediately\n10. ✅ Continue button disabled until all required fields valid\n11. ✅ Back button returns to previous step\n12. ✅ Existing data is restored if user returns to draft\n\n**UI/UX:**\n1. ✅ All inputs show focus states with blue ring\n2. ✅ Required fields marked with red asterisk\n3. ✅ Signature canvas shows drawing feedback\n4. ✅ Text signature modal appears centered\n5. ✅ Auto-save indicator shows when saving\n6. ✅ Success indicator appears briefly after save\n7. ✅ Mobile-responsive design (inputs stack properly)\n8. ✅ Radio buttons and checkboxes are clickable and accessible\n9. ✅ Date picker uses native browser date selector\n10. ✅ Textarea auto-expands or has scroll for long text\n\n**Integration:**\n1. ✅ API endpoint: `GET /api/student/submissions/{id}/form-fields`\n2. ✅ API endpoint: `POST /api/student/submissions/{id}/form-draft`\n3. ✅ API endpoint: `POST /api/student/submissions/{id}/form-data`\n4. ✅ API endpoint: `POST /api/student/submissions/{id}/complete-form`\n5. ✅ Token authentication in headers\n6. ✅ Form data and signature data sent to server\n7. ✅ State persistence in Pinia store\n8. ✅ Data restored on page reload\n\n**Security:**\n1. ✅ Token-based authentication required\n2. ✅ Authorization check: student can only fill their submission\n3. ✅ Input validation (client-side + server-side)\n4. ✅ XSS prevention (sanitized input)\n5. ✅ Rate limiting on save endpoints\n6. ✅ Audit log of all form saves\n\n**Quality:**\n1. ✅ Auto-save doesn\'t interfere with user typing\n2. ✅ Network errors handled gracefully\n3. ✅ No memory leaks (clean up intervals)\n4. ✅ Performance: handles 50+ fields without lag\n5. ✅ Browser compatibility: Chrome, Firefox, Safari, Edge",
|
|
},
|
|
{
|
|
number: "5.3",
|
|
title: "Student Portal - Progress Tracking & Save Draft",
|
|
user_story: "**As a** Student,\n**I want** to see my overall progress and save my work as a draft at any time,\n**So that** I can complete the submission at my own pace without losing work.",
|
|
background: "Students may need multiple sessions to complete their submission:\n1. Upload documents (Story 5.1)\n2. Fill form fields (Story 5.2)\n3. Review and submit (Story 5.4)\n\nThe student portal must provide:\n- **Progress Dashboard**: Visual overview of all steps and their status\n- **Draft Management**: Save and resume capability\n- **Session Persistence**: Data survives browser refresh\n- **Multi-step Navigation**: Jump between steps\n- **Completion Indicators**: Clear visual feedback\n\nThis story implements the progress tracking UI that shows all three steps (Upload, Form, Review) with their completion status, and provides a persistent \"Save Draft\" mechanism accessible from any step.\n\n**Integration Point**: This ties together Stories 5.1 and 5.2, providing the navigation layer that orchestrates the complete student workflow.",
|
|
acceptance: "**Functional:**\n1. ✅ Dashboard loads progress data on mount\n2. ✅ Shows correct overall progress percentage\n3. ✅ Displays all 3 steps with correct status\n4. ✅ Step cards show completion indicators (checkmark, numbers)\n5. ✅ Progress bars animate smoothly\n6. ✅ Status badge shows correct text and color\n7. ✅ Last saved timestamp updates correctly\n8. ✅ \"Save Draft\" button works and shows feedback\n9. ✅ \"Submit for Review\" only enabled when all steps complete\n10. ✅ \"Resume Workflow\" directs to appropriate step\n11. ✅ Clicking step cards navigates to that step\n12. ✅ Auto-save triggers every 30 seconds if changes detected\n\n**UI/UX:**\n1. ✅ Step cards have hover effects (lift, shadow)\n2. ✅ Active step shows ring highlight\n3. ✅ Progress bars animate from 0 to current value\n4. ✅ Status badge uses color-coded styling\n5. ✅ Last saved time formats correctly (just now, Xm ago, Xh ago)\n6. ✅ Success toast appears after save\n7. ✅ Loading state during save\n8. ✅ Mobile-responsive layout\n9. ✅ Step cards are clickable and show cursor pointer\n10. ✅ Help modal provides clear instructions\n\n**Integration:**\n1. ✅ API endpoint: `GET /api/student/submissions/{id}/progress`\n2. ✅ API endpoint: `POST /api/student/submissions/{id}/save-draft`\n3. ✅ API endpoint: `POST /api/student/submissions/{id}/submit`\n4. ✅ Token authentication in headers\n5. ✅ Navigation emits events to parent\n6. ✅ Progress data reflects uploads and form completion\n\n**Security:**\n1. ✅ Token-based authentication required\n2. ✅ Authorization check: student can only view their submission\n3. ✅ Submit endpoint validates all steps complete\n4. ✅ Rate limiting on save endpoints\n5. ✅ Audit log of all saves and submissions\n\n**Quality:**\n1. ✅ Auto-save doesn\'t trigger if no changes\n2. ✅ Navigation prevents invalid transitions\n3. ✅ Error handling for failed API calls\n4. ✅ No memory leaks (clean up intervals)\n5. ✅ Performance: loads in <2 seconds",
|
|
},
|
|
{
|
|
number: "5.4",
|
|
title: "Student Portal - Submission Confirmation & Status",
|
|
user_story: "**As a** Student,\n**I want** to review my complete submission and receive confirmation of successful submission,\n**So that** I can verify everything is correct and track when the sponsor signs.",
|
|
background: "After completing all three steps (upload, form filling, review), students need to:\n1. **Final Review**: See a summary of all uploaded documents and filled fields\n2. **Confirmation**: Receive clear confirmation that submission was successful\n3. **Status Tracking**: Monitor progress through sponsor signature and TP review phases\n4. **Email Notifications**: Get updates when status changes\n\nThis is the final step in the student workflow. The student portal must provide:\n- Complete submission summary\n- Clear success confirmation\n- Real-time status updates\n- Email notification settings\n- Access to final document once complete\n\n**Status Flow:**\n- **Pending**: Student hasn\'t submitted yet\n- **In Review**: Submitted, waiting for sponsor\n- **Sponsor Signed**: Sponsor completed their part\n- **TP Reviewed**: TP completed final review\n- **Completed**: All parties finished, document finalized\n\n**Integration Point**: This story completes the student portal frontend (Phase 5). It connects to the sponsor portal (Phase 6) and TP review (Phase 4).",
|
|
acceptance: "**Functional:**\n1. ✅ Component loads status data on mount\n2. ✅ Shows success banner on fresh submission\n3. ✅ Displays timeline with all 4 stages\n4. ✅ Updates timeline icons based on status\n5. ✅ Shows uploaded documents list with sizes\n6. ✅ Shows completed fields with values\n7. ✅ Displays estimated completion time\n8. ✅ Refresh button fetches latest status\n9. ✅ Download button works when completed\n10. ✅ Notification settings can be updated\n11. ✅ Contact support opens email client\n12. ✅ Polling updates status every 60 seconds\n\n**UI/UX:**\n1. ✅ Success banner can be dismissed\n2. ✅ Timeline shows connector lines between stages\n3. ✅ Status badges use color-coded styling\n4. ✅ Current stage is highlighted\n5. ✅ Completed stages show green checkmarks\n6. ✅ Pending stages show appropriate icons\n7. ✅ Document list shows file sizes formatted\n8. ✅ Field values are displayed clearly\n9. ✅ Toast notifications show after actions\n10. ✅ Mobile-responsive design\n\n**Integration:**\n1. ✅ API endpoint: `GET /api/student/submissions/{id}/status`\n2. ✅ API endpoint: `GET /api/student/submissions/{id}/download`\n3. ✅ API endpoint: `POST /api/student/submissions/{id}/notifications`\n4. ✅ Token authentication in headers\n5. ✅ Polling mechanism with cleanup\n6. ✅ Data reflects actual submission state\n\n**Security:**\n1. ✅ Token-based authentication required\n2. ✅ Authorization check: student can only view their submission\n3. ✅ Download endpoint validates completion\n4. ✅ Rate limiting on status refresh (max 30 per hour)\n5. ✅ Audit log of all downloads\n\n**Quality:**\n1. ✅ Polling stops when component unmounts\n2. ✅ Error handling for failed API calls\n3. ✅ No duplicate polling intervals\n4. ✅ Performance: loads in <1 second\n5. ✅ Data consistency across refreshes",
|
|
},
|
|
{
|
|
number: "5.5",
|
|
title: "Student Portal - Email Notifications & Reminders",
|
|
user_story: "**As a** Student,\n**I want** to receive email notifications for status updates and reminders to complete my submission,\n**So that** I can stay informed and complete my work on time without constantly checking the portal.",
|
|
background: "Students need to stay informed about their submission progress without manually checking the portal. The system should provide:\n\n1. **Initial Invitation Email**: Sent when cohort is created, contains access link with token\n2. **Reminder Emails**: Sent if student hasn\'t started or hasn\'t completed after certain time\n3. **Status Update Emails**: Sent when key milestones are reached\n4. **Final Completion Email**: Sent when document is fully signed and ready\n\n**Email Types:**\n- **Invitation**: \"You\'ve been invited to join [Cohort Name]\"\n- **Reminder - Not Started**: \"Don\'t forget to complete your submission\"\n- **Reminder - Incomplete**: \"You\'re almost there! Finish your submission\"\n- **Status - Sponsor Signed**: \"Sponsor has signed your document\"\n- **Status - Completed**: \"Your document is ready!\"\n- **TP Reminder**: (TP sends to students who haven\'t completed)\n\n**Key Requirements:**\n- Emails contain secure, time-limited links\n- Links use JWT tokens (Story 2.2, 2.3)\n- Unsubscribe option in all emails\n- Email preferences can be managed\n- Reminder frequency is configurable\n- Email templates are customizable\n\n**Integration Point**: This story connects to the email system (Story 2.2, 2.3) and provides the student-facing notification preferences.",
|
|
acceptance: "**Functional:**\n1. ✅ Component loads existing preferences on mount\n2. ✅ All 4 notification toggles work correctly\n3. ✅ Reminder frequency radio buttons work\n4. ✅ Save button persists changes to server\n5. ✅ Reset to defaults restores original settings\n6. ✅ Unsubscribe all disables all notifications\n7. ✅ Confirmation dialog before unsubscribe\n8. ✅ Email preview updates based on settings\n9. ✅ Shows success toast after save\n10. ✅ Loading state during API calls\n\n**UI/UX:**\n1. ✅ Toggles show clear on/off states\n2. ✅ Settings organized in logical sections\n3. ✅ Warning section visually distinct (red border)\n4. ✅ Email preview shows realistic example\n5. ✅ Success toast appears for 2 seconds\n6. ✅ Loading overlay blocks interaction\n7. ✅ Mobile-responsive design\n8. ✅ Hover states on all interactive elements\n\n**Integration:**\n1. ✅ API endpoint: `GET /api/student/submissions/{id}/notification-preferences`\n2. ✅ API endpoint: `PUT /api/student/submissions/{id}/notification-preferences`\n3. ✅ API endpoint: `POST /api/student/submissions/{id}/send-invitation`\n4. ✅ API endpoint: `POST /api/student/submissions/{id}/send-reminder`\n5. ✅ Token authentication in headers\n6. ✅ Settings persist across sessions\n\n**Security:**\n1. ✅ Token-based authentication required\n2. ✅ Authorization check: student can only manage their preferences\n3. ✅ Rate limiting on update endpoint (max 10 per hour)\n4. ✅ Validation of reminder frequency values\n5. ✅ Audit log of all preference changes\n\n**Quality:**\n1. ✅ No duplicate API calls on rapid clicks\n2. ✅ Error handling for failed API calls\n3. ✅ State consistency between UI and server\n4. ✅ Performance: loads in <1 second\n5. ✅ Browser compatibility: Chrome, Firefox, Safari, Edge",
|
|
},
|
|
{
|
|
number: "6.1",
|
|
title: "Sponsor Portal - Cohort Dashboard & Bulk Signing Interface",
|
|
user_story: "**As a** Sponsor,\n**I want** to view all pending student documents in a cohort and sign them all at once,\n**So that** I can efficiently complete my signing responsibility without reviewing each submission individually.",
|
|
background: "Sponsors receive a single email per cohort (per FR12) with a secure link to the sponsor portal. Upon accessing the portal, they see:\n\n1. **Cohort Overview**: Name, total students, completion status\n2. **Student List**: All students with their completion status\n3. **Bulk Signing**: Sign once to apply to all pending submissions\n4. **Progress Tracking**: Real-time updates of signing progress\n\n**Key Requirements:**\n- Single signing action for entire cohort\n- Preview of what will be signed\n- Clear indication of which students are affected\n- Confirmation before signing\n- Immediate status update after signing\n- Email confirmation to TP after sponsor signs\n\n**Workflow:**\n1. Sponsor clicks email link with token\n2. Portal loads cohort dashboard\n3. Sponsor reviews student list\n4. Sponsor signs once (signature or typed name)\n5. System applies signature to all student submissions\n6. Status updates to \"Sponsor Signed\"\n7. TP receives notification\n8. Students receive status update email\n\n**Integration Point**: This story connects to the email system (Story 2.2, 2.3) and the backend signing workflow (Stories 2.5, 2.6).",
|
|
acceptance: "**Functional:**\n1. ✅ Component loads cohort data on mount\n2. ✅ Shows correct student counts (total, pending, completed)\n3. ✅ Displays student list with status\n4. ✅ Search filters students by name/email\n5. ✅ Status filter works correctly\n6. ✅ Signature method selection works\n7. ✅ Canvas signature drawing works\n8. ✅ Typed signature input works\n9. ✅ Clear signature button works\n10. ✅ Confirmation checkbox required\n11. ✅ Preview modal shows affected students\n12. ✅ Preview modal shows signature preview\n13. ✅ Bulk sign executes successfully\n14. ✅ Success modal appears after signing\n15. ✅ Data refreshes after signing\n\n**UI/UX:**\n1. ✅ Desktop: Table layout with 5 columns\n2. ✅ Mobile: Card layout with stacked information\n3. ✅ Status badges use color-coded styling\n4. ✅ Progress bars animate smoothly\n5. ✅ Quick stats cards show key metrics\n6. ✅ Signature canvas shows drawing feedback\n7. ✅ Modals are centered and scrollable\n8. ✅ Loading overlay blocks interaction\n9. ✅ Success modal shows confirmation\n10. ✅ Toast notifications for errors\n\n**Integration:**\n1. ✅ API endpoint: `GET /api/sponsor/cohorts/{id}`\n2. ✅ API endpoint: `POST /api/sponsor/cohorts/{id}/bulk-sign`\n3. ✅ Token authentication in headers\n4. ✅ Signature data sent correctly\n5. ✅ State updates after signing\n\n**Security:**\n1. ✅ Token-based authentication required\n2. ✅ Authorization check: sponsor can only sign their assigned cohorts\n3. ✅ Validation: all required fields before signing\n4. ✅ Rate limiting on bulk sign (max 5 per hour)\n5. ✅ Audit log of all signing actions\n\n**Quality:**\n1. ✅ No duplicate signing attempts\n2. ✅ Error handling for failed API calls\n3. ✅ Data consistency after signing\n4. ✅ Performance: handles 100+ students\n5. ✅ Browser compatibility: Chrome, Firefox, Safari, Edge",
|
|
},
|
|
{
|
|
number: "6.2",
|
|
title: "Sponsor Portal - Email Notifications & Reminders",
|
|
user_story: "**As a** Sponsor,\n**I want** to receive email notifications about signing requests and reminders to complete my cohort signing,\n**So that** I can stay informed and fulfill my signing responsibility on time without constantly checking the portal.",
|
|
background: "Sponsors need to stay informed about their signing responsibilities without manually monitoring the portal. The system should provide:\n\n1. **Initial Invitation Email**: Sent when TP creates cohort and assigns sponsor\n2. **Reminder Emails**: Sent if sponsor hasn\'t accessed the cohort after certain time\n3. **Status Update Emails**: Sent when students complete their submissions\n4. **Completion Confirmation**: Sent after sponsor completes bulk signing\n\n**Email Types:**\n- **Invitation**: \"You\'ve been assigned to sign documents for [Cohort Name]\"\n- **Reminder - Not Accessed**: \"Action required: Sign documents for [Cohort Name]\"\n- **Reminder - Partial**: \"You\'re almost done! [X] students still need your signature\"\n- **Status - Student Completed**: \"[Student Name] has submitted their documents\"\n- **Status - Signing Complete**: \"You\'ve successfully signed all documents\"\n\n**Key Requirements:**\n- Emails contain secure, time-limited links with JWT tokens\n- Unsubscribe option in all emails (per FR12)\n- Email preferences can be managed by sponsor\n- Reminder frequency is configurable\n- Single email per cohort (no duplicates per student)\n- Immediate notification when students complete submissions\n\n**Integration Point**: This story connects to the email system (Stories 2.2, 2.3) and provides sponsor-facing notification management.",
|
|
acceptance: "**Functional:**\n1. ✅ Component loads existing preferences on mount\n2. ✅ All 4 notification toggles work correctly\n3. ✅ Reminder frequency radio buttons work\n4. ✅ Save button persists changes to server\n5. ✅ Reset to defaults restores original settings\n6. ✅ Unsubscribe all disables all notifications\n7. ✅ Confirmation dialog before unsubscribe\n8. ✅ Email preview shows realistic example\n9. ✅ Shows success toast after save\n10. ✅ Loading state during API calls\n\n**UI/UX:**\n1. ✅ Toggles show clear on/off states\n2. ✅ Settings organized in logical sections\n3. ✅ Warning section visually distinct (red border)\n4. ✅ Email preview shows realistic example\n5. ✅ Success toast appears for 2 seconds\n6. ✅ Loading overlay blocks interaction\n7. ✅ Mobile-responsive design\n8. ✅ Hover states on all interactive elements\n\n**Integration:**\n1. ✅ API endpoint: `GET /api/sponsor/cohorts/{id}/notification-preferences`\n2. ✅ API endpoint: `PUT /api/sponsor/cohorts/{id}/notification-preferences`\n3. ✅ API endpoint: `POST /api/sponsor/cohorts/{id}/send-invitation`\n4. ✅ API endpoint: `POST /api/sponsor/cohorts/{id}/send-reminder`\n5. ✅ API endpoint: `POST /api/sponsor/cohorts/{id}/send-student-alert`\n6. ✅ Token authentication in headers\n7. ✅ Settings persist across sessions\n\n**Security:**\n1. ✅ Token-based authentication required\n2. ✅ Authorization check: sponsor can only manage their preferences\n3. ✅ Rate limiting on update endpoint (max 10 per hour)\n4. ✅ Validation of reminder frequency values\n5. ✅ Audit log of all preference changes\n\n**Quality:**\n1. ✅ No duplicate API calls on rapid clicks\n2. ✅ Error handling for failed API calls\n3. ✅ State consistency between UI and server\n4. ✅ Performance: loads in <1 second\n5. ✅ Browser compatibility: Chrome, Firefox, Safari, Edge",
|
|
},
|
|
{
|
|
number: "7.1",
|
|
title: "End-to-End Workflow Testing",
|
|
user_story: "**As a** QA Engineer,\n**I want** to test the complete 3-portal workflow from start to finish,\n**So that** I can verify all integrations work correctly and identify any breaking issues before production deployment.",
|
|
background: "This story validates the entire FloDoc system through complete end-to-end testing. The workflow must be tested in sequence:\n\n1. **TP Portal**: Create cohort, configure template, assign sponsor, sign first student\n2. **Student Portal**: Receive invitation, upload documents, fill forms, submit\n3. **Sponsor Portal**: Receive notification, sign all documents at once\n4. **TP Portal**: Review and finalize cohort\n\n**Key Testing Scenarios:**\n- **Happy Path**: All parties complete their steps successfully\n- **Edge Cases**: Invalid tokens, expired sessions, network failures\n- **State Transitions**: Proper status updates at each step\n- **Email Delivery**: All notifications sent and received\n- **Data Integrity**: No data loss or corruption\n- **Concurrent Access**: Multiple users accessing same cohort\n- **Error Recovery**: Graceful handling of failures\n\n**Test Data Requirements:**\n- Multiple cohorts with varying student counts (1, 5, 25, 100)\n- Different document types (PDF, images)\n- Various form field types (signature, text, date, checkbox)\n- Different signature methods (draw, type)\n\n**Integration Points to Verify:**\n- Template → Cohort mapping\n- Student → Submission mapping\n- Bulk signing → Individual student updates\n- Email triggers → Actual email delivery\n- Token generation → Token validation\n- State machine transitions\n- Excel export data accuracy",
|
|
acceptance: "**Functional:**\n1. ✅ Complete workflow tested with 5 students\n2. ✅ Complete workflow tested with 25 students\n3. ✅ Complete workflow tested with 100 students\n4. ✅ All edge cases handled (expired tokens, network failures, etc.)\n5. ✅ Concurrent access scenarios tested\n6. ✅ Data integrity verified throughout\n7. ✅ Email delivery verified in correct sequence\n8. ✅ State transitions validated\n9. ✅ Error recovery tested\n10. ✅ Performance benchmarks met\n\n**Integration:**\n1. ✅ TP Portal → Student Portal handoff verified\n2. ✅ Student Portal → Sponsor Portal handoff verified\n3. ✅ Sponsor Portal → TP Portal handoff verified\n4. ✅ Email system integration verified\n5. ✅ Token system integration verified\n6. ✅ Database state consistency verified\n7. ✅ API endpoints tested end-to-end\n\n**Security:**\n1. ✅ Token validation enforced throughout\n2. ✅ Authorization checks at each step\n3. ✅ No data leakage between users\n4. ✅ Rate limiting tested\n5. ✅ Audit trail completeness verified\n\n**Performance:**\n1. ✅ 100-student cohort completes within 5 seconds\n2. ✅ Email delivery within 10 seconds\n3. ✅ API response times < 500ms\n4. ✅ No memory leaks in long-running sessions\n\n**Quality:**\n1. ✅ 100% test coverage for critical paths\n2. ✅ All tests pass consistently\n3. ✅ No flaky tests\n4. ✅ Test data cleanup verified",
|
|
},
|
|
{
|
|
number: "7.2",
|
|
title: "Mobile Responsiveness Testing",
|
|
user_story: "**As a** QA Engineer,\n**I want** to test all three portals across different screen sizes and devices,\n**So that** I can ensure the FloDoc system works perfectly on mobile, tablet, and desktop devices.",
|
|
background: "FloDoc must work seamlessly across all device types:\n- **Mobile**: 320px - 640px (smartphones)\n- **Tablet**: 641px - 1024px (iPad, Android tablets)\n- **Desktop**: 1025px+ (laptops, monitors)\n\n**Portal-Specific Mobile Requirements:**\n\n**TP Portal**:\n- Complex admin interface must remain usable\n- Bulk operations need touch-friendly targets\n- Data tables must be responsive\n- Navigation must collapse to hamburger menu\n- Forms must stack vertically\n- Progress indicators must be visible\n\n**Student Portal**:\n- Mobile-first design (primary use case)\n- Maximum 3 clicks to complete any action\n- Touch targets minimum 44x44px\n- File upload must work with mobile camera\n- Form fields must be mobile-optimized\n- Progress tracking must be clear\n\n**Sponsor Portal**:\n- Bulk signing must work on touch devices\n- Signature canvas must support touch drawing\n- Student list must be scrollable\n- Preview modal must be mobile-friendly\n- Action buttons must be thumb-accessible\n\n**Testing Scenarios:**\n- **Viewport Sizes**: Test at 10+ breakpoints\n- **Orientation**: Portrait and landscape modes\n- **Touch Gestures**: Swipe, tap, pinch, scroll\n- **Input Methods**: Touch, keyboard, mouse\n- **Browser Compatibility**: Chrome, Safari, Firefox on mobile\n- **OS Compatibility**: iOS, Android\n\n**Critical Components to Test:**\n- Navigation menus\n- Forms and inputs\n- Tables and lists\n- Modals and dialogs\n- Buttons and links\n- File uploads\n- Signature capture\n- Progress indicators\n- Error messages\n- Loading states",
|
|
acceptance: "**Functional:**\n1. ✅ All portals render correctly on 375px (mobile)\n2. ✅ All portals render correctly on 768px (tablet)\n3. ✅ All portals render correctly on 1280px (desktop)\n4. ✅ Touch targets are minimum 44x44px everywhere\n5. ✅ Forms are mobile-optimized (proper input types)\n6. ✅ Navigation collapses to hamburger on mobile\n7. ✅ Tables scroll horizontally on small screens\n8. ✅ Modals are full-screen on mobile\n9. ✅ Signature canvas works with touch\n10. ✅ File upload works with mobile camera\n\n**UI/UX:**\n1. ✅ Portrait and landscape modes work\n2. ✅ Swipe gestures work correctly\n3. ✅ Pinch-to-zoom works on document preview\n4. ✅ Long press shows context menus\n5. ✅ Loading states are visible on all sizes\n6. ✅ Error messages are readable on mobile\n7. ✅ Buttons are thumb-accessible\n8. ✅ Text is readable without zoom\n\n**Integration:**\n1. ✅ All portals maintain consistent design\n2. ✅ Responsive breakpoints work across portals\n3. ✅ Touch events propagate correctly\n4. ✅ Keyboard navigation works on tablets\n5. ✅ Mouse events don\'t break touch\n\n**Security:**\n1. ✅ No sensitive data exposed in mobile view\n2. ✅ Touch events don\'t bypass security\n3. ✅ Mobile camera upload is secure\n4. ✅ Session management works on mobile\n\n**Quality:**\n1. ✅ Tests pass on all viewport sizes\n2. ✅ Visual regression tests pass\n3. ✅ Accessibility tests pass (WCAG 2.1 AA)\n4. ✅ No horizontal scroll on content\n5. ✅ Performance is acceptable on mobile",
|
|
},
|
|
{
|
|
number: "7.3",
|
|
title: "Performance Testing (50+ Students)",
|
|
user_story: "**As a** QA Engineer,\n**I want** to test system performance with large cohorts (50+ students),\n**So that** I can ensure FloDoc scales efficiently and meets NFR requirements.",
|
|
background: "Performance is critical for production success. This story validates:\n- **Load Time**: Pages must load within acceptable timeframes\n- **Database Queries**: No N+1 queries, optimized indexes\n- **Memory Usage**: No memory leaks, efficient garbage collection\n- **Concurrent Users**: System must handle multiple users simultaneously\n- **Large Cohorts**: 50, 100, even 500 students per cohort\n- **Bulk Operations**: Signing 100+ students at once\n- **Excel Export**: Generate large files without timeout\n- **Email Delivery**: Queue and send 100+ emails efficiently\n\n**Performance Requirements (from NFRs):**\n- Page load time: <2 seconds\n- API response time: <500ms\n- Bulk signing: <5 seconds for 100 students\n- Excel export: <10 seconds for 100 rows\n- Email queue: Process 100 emails in <30 seconds\n- Memory growth: <10% per operation\n- Database queries: <20 per page load\n\n**Test Scenarios:**\n1. **Cohort Creation**: Create cohort with 100 students\n2. **Student Upload**: 100 students uploading documents simultaneously\n3. **Bulk Signing**: Sponsor signs 100 students at once\n4. **Excel Export**: Export 100 student records\n5. **Email Blast**: Send 100 invitation emails\n6. **Concurrent Access**: 10 users accessing same cohort\n7. **Database Load**: Complex queries with large datasets\n8. **Memory Leak**: Long-running sessions over hours\n\n**Tools and Monitoring:**\n- **Rails Panel**: Query count and time\n- **Bullet**: N+1 query detection\n- **rack-mini-profiler**: Performance profiling\n- **memory_profiler**: Memory usage tracking\n- **New Relic**: Production monitoring simulation\n- **JMeter**: Load testing\n- **PgHero**: Database performance",
|
|
acceptance: "**Functional:**\n1. ✅ Cohort creation with 100 students <2 seconds\n2. ✅ Bulk signing 100 students <5 seconds\n3. ✅ Excel export 100 rows <10 seconds\n4. ✅ Email queue 100 messages <30 seconds\n5. ✅ Concurrent access (10 users) <2 seconds\n6. ✅ Student uploads (100 concurrent) <5 seconds\n7. ✅ Database queries <20 per page load\n8. ✅ API responses <500ms average\n\n**Performance:**\n1. ✅ No N+1 queries detected\n2. ✅ Proper database indexes used\n3. ✅ Memory growth <10% per operation\n4. ✅ No memory leaks over 10 iterations\n5. ✅ Object creation <1000 per operation\n6. ✅ GC overhead <5% of total time\n7. ✅ Sustained load (100 req/min) <60s total\n\n**Database:**\n1. ✅ All queries use indexes\n2. ✅ No SELECT * queries\n3. ✅ Transactions used for bulk operations\n4. ✅ Query count optimized\n5. ✅ Table sizes reasonable\n\n**Quality:**\n1. ✅ All performance tests pass consistently\n2. ✅ No flaky performance tests\n3. ✅ Performance metrics documented\n4. ✅ Bottlenecks identified and documented\n5. ✅ Recommendations provided",
|
|
},
|
|
{
|
|
number: "7.4",
|
|
title: "Security Audit & Penetration Testing",
|
|
user_story: "**As a** Security Engineer,\n**I want** to perform comprehensive security testing on all three portals,\n**So that** I can identify and remediate vulnerabilities before production deployment.",
|
|
background: "Security is paramount for a document signing platform handling sensitive student data. This story validates:\n\n**Authentication Security:**\n- JWT token generation and validation\n- Token expiration and renewal mechanisms\n- Ad-hoc access pattern security (no account creation)\n- Token leakage prevention\n- Session management\n\n**Authorization Security:**\n- Role-based access control (TP, Student, Sponsor)\n- Cross-portal access prevention\n- Data isolation between cohorts\n- Proper Cancancan ability definitions\n- API endpoint protection\n\n**Data Security:**\n- Student PII protection (names, emails, documents)\n- Document encryption at rest\n- Secure file uploads (content validation)\n- GDPR compliance (data retention, deletion)\n- Audit trail integrity\n\n**Input Validation:**\n- SQL injection prevention\n- XSS prevention (Vue templates, form inputs)\n- File upload validation (type, size, content)\n- API parameter sanitization\n- Mass assignment protection\n\n**Web Security:**\n- CSRF protection\n- CORS configuration\n- HTTPS enforcement\n- Secure headers (CSP, HSTS, X-Frame-Options)\n- Clickjacking prevention\n\n**Email Security:**\n- Email spoofing prevention\n- Link tampering protection\n- Token expiration in emails\n- Secure email templates\n\n**Third-Party Security:**\n- DocuSeal API integration security\n- Webhook signature verification\n- External service authentication\n\n**Compliance:**\n- OWASP Top 10 coverage\n- GDPR data protection requirements\n- Audit logging for all sensitive operations",
|
|
acceptance: "**Authentication Security:**\n1. ✅ JWT tokens are cryptographically signed and validated\n2. ✅ Token expiration enforced (30 days default)\n3. ✅ Token renewal mechanism works without data loss\n4. ✅ Expired tokens rejected with proper error\n5. ✅ Old tokens invalidated after renewal\n6. ✅ Ad-hoc access tokens contain no sensitive data\n7. ✅ Rate limiting prevents brute force attacks\n\n**Authorization Security:**\n1. ✅ Role-based access control enforced (TP, Student, Sponsor)\n2. ✅ Cross-portal access prevented\n3. ✅ Data isolation between cohorts enforced\n4. ✅ Cancancan abilities properly defined\n5. ✅ API endpoints protected by authorization\n6. ✅ Horizontal privilege escalation prevented\n7. ✅ Vertical privilege escalation prevented\n\n**Data Security:**\n1. ✅ Documents encrypted at rest (Active Storage)\n2. ✅ Sensitive fields encrypted in database\n3. ✅ PII properly sanitized and validated\n4. ✅ GDPR retention policies enforced\n5. ✅ Audit logs capture all sensitive operations\n6. ✅ Data export includes complete user data\n7. ✅ Data deletion properly anonymizes\n\n**Input Validation:**\n1. ✅ SQL injection prevented (parameterized queries)\n2. ✅ XSS prevented (input sanitization, CSP headers)\n3. ✅ File upload validation (type, size, content)\n4. ✅ API parameter sanitization\n5. ✅ Mass assignment protection\n6. ✅ No malicious file types accepted\n7. ✅ File size limits enforced\n\n**Web Security:**\n1. ✅ CSRF protection enabled\n2. ✅ CORS properly configured\n3. ✅ HTTPS enforced\n4. ✅ Secure headers present (CSP, HSTS, X-Frame-Options)\n5. ✅ Clickjacking prevention\n6. ✅ No open redirects\n7. ✅ Session fixation prevented\n\n**Email Security:**\n1. ✅ Email spoofing prevented (SPF, DKIM)\n2. ✅ Secure tokens in emails with expiration\n3. ✅ Token leakage prevented in logs\n4. ✅ Email templates properly sanitized\n5. ✅ Link tampering protection\n\n**Third-Party Security:**\n1. ✅ DocuSeal API responses validated\n2. ✅ Webhook signature verification\n3. ✅ Replay attack prevention\n4. ✅ External service authentication secure\n5. ✅ No sensitive data in webhook payloads\n\n**Compliance:**\n1. ✅ OWASP Top 10 coverage verified\n2. ✅ GDPR compliance validated\n3. ✅ Audit trail integrity maintained\n4. ✅ Data retention policies implemented\n5. ✅ User data export functionality works\n\n**Testing Coverage:**\n1. ✅ All security tests pass\n2. ✅ OWASP ZAP scan clean (or critical issues documented)\n3. ✅ Brakeman shows no high-severity warnings\n4. ✅ Penetration test scenarios pass\n5. ✅ Security monitoring alerts functional",
|
|
},
|
|
{
|
|
number: "7.5",
|
|
title: "User Acceptance Testing",
|
|
user_story: "**As a** Product Owner,\n**I want** to conduct comprehensive user acceptance testing with real stakeholders,\n**So that** I can validate the system meets business requirements and user needs before production launch.",
|
|
background: "User Acceptance Testing (UAT) is the final validation phase where real users test the complete system in a production-like environment. This story validates:\n\n**Stakeholder Testing:**\n- **Training Provider (TP)**: Creates cohorts, manages students, reviews submissions\n- **Students**: Upload documents, fill forms, sign documents\n- **Sponsors**: Bulk sign documents, track progress\n\n**Workflow Validation:**\n- Complete end-to-end cohort lifecycle\n- All three portals working together\n- Email notifications delivered correctly\n- Document signing workflow complete\n- Excel export functionality\n- Token renewal and session management\n\n**Real-World Scenarios:**\n- Large cohorts (50+ students)\n- Multiple concurrent users\n- Different document types\n- Various form field types\n- Edge cases and error handling\n\n**Business Process Validation:**\n- TP creates cohort with 50 students\n- TP signs first student\'s document\n- System auto-fills TP signature to all students\n- Students receive emails and upload documents\n- Students fill forms and sign\n- Sponsor receives ONE email for entire cohort\n- Sponsor bulk signs all students\n- TP reviews and finalizes cohort\n- Excel export contains all data\n\n**UX/Usability Testing:**\n- Intuitive navigation across portals\n- Clear user instructions\n- Mobile responsiveness\n- Accessibility compliance\n- Performance under real usage\n\n**Data Integrity:**\n- No data loss during workflow\n- Proper audit trail\n- Correct document generation\n- Accurate state management\n- Proper error recovery",
|
|
acceptance: "**TP Portal UAT:**\n1. ✅ Can create cohort with 50+ students in <2 seconds\n2. ✅ Can upload and configure template PDF\n3. ✅ Can sign first document and auto-fill to all students\n4. ✅ Can monitor real-time progress across all students\n5. ✅ Can export complete cohort data to Excel\n6. ✅ Can finalize cohort after sponsor approval\n7. ✅ Email notifications delivered correctly\n8. ✅ Token renewal works without data loss\n9. ✅ Mobile responsive on tablets and phones\n10. ✅ No data loss during any operation\n\n**Student Portal UAT:**\n1. ✅ Can access portal via email link\n2. ✅ Can upload required documents\n3. ✅ Can fill all 12 field types correctly\n4. ✅ Can sign documents with signature pad\n5. ✅ Can save drafts and resume later\n6. ✅ Receives timely email notifications\n7. ✅ Cannot access other students\' documents\n8. ✅ Mobile responsive and touch-friendly\n9. ✅ WCAG 2.1 AA accessibility compliant\n10. ✅ Clear error messages and guidance\n\n**Sponsor Portal UAT:**\n1. ✅ Can access portal via email link\n2. ✅ Can bulk sign all students at once\n3. ✅ Can track progress across three tabs (Waiting/In Progress/Completed)\n4. ✅ Receives exactly ONE email per cohort\n5. ✅ No duplicate email notifications\n6. ✅ Mobile responsive on all devices\n7. ✅ WCAG 2.1 AA accessibility compliant\n8. ✅ Signature appears on all student documents\n9. ✅ Cannot access other cohorts\n10. ✅ Clear progress indicators\n\n**End-to-End Workflow UAT:**\n1. ✅ Complete 3-party workflow succeeds\n2. ✅ TP signs first, auto-fills to all students\n3. ✅ All students receive emails and can complete\n4. ✅ Sponsor receives single email notification\n5. ✅ Sponsor bulk signs all students\n6. ✅ TP reviews and finalizes cohort\n7. ✅ Excel export contains complete data\n8. ✅ Audit trail captures all events\n9. ✅ No data corruption or loss\n10. ✅ All state transitions work correctly\n\n**Performance UAT:**\n1. ✅ Cohort creation with 50 students <2 seconds\n2. ✅ Bulk signing 50 students <5 seconds\n3. ✅ Excel export 50 rows <10 seconds\n4. ✅ Email delivery 50 messages <30 seconds\n5. ✅ Concurrent access (10 users) <2 seconds\n6. ✅ Student uploads (50 concurrent) <5 seconds\n7. ✅ Database queries <20 per page load\n8. ✅ API responses <500ms average\n9. ✅ No memory leaks\n10. ✅ No N+1 queries\n\n**Security UAT:**\n1. ✅ Tokens expire after 30 days\n2. ✅ Token renewal works without data loss\n3. ✅ Expired tokens rejected with clear error\n4. ✅ Cross-portal access prevented\n5. ✅ Data isolation between cohorts enforced\n6. ✅ No SQL injection vulnerabilities\n7. ✅ No XSS vulnerabilities\n8. ✅ All sensitive operations logged\n9. ✅ GDPR compliance validated\n10. ✅ No unauthorized access possible\n\n**UX/Usability UAT:**\n1. ✅ Navigation is intuitive across all portals\n2. ✅ User instructions are clear and helpful\n3. ✅ Error messages are actionable\n4. ✅ Success feedback is provided\n5. ✅ Loading states are clear\n6. ✅ Mobile experience is excellent\n7. ✅ Desktop experience is excellent\n8. ✅ Touch gestures work on mobile\n9. ✅ Keyboard navigation works\n10. ✅ Screen readers work correctly\n\n**Data Integrity UAT:**\n1. ✅ No data loss during workflow\n2. ✅ All documents generated correctly\n3. ✅ All signatures appear correctly\n4. ✅ Audit trail is complete and accurate\n5. ✅ State management is correct\n6. ✅ Email delivery is reliable\n7. ✅ Excel export is accurate\n8. ✅ Token system works correctly\n9. ✅ Error recovery works\n10. ✅ Data consistency maintained",
|
|
},
|
|
{
|
|
number: "8.0",
|
|
title: "Development Infrastructure Setup (Local Docker)",
|
|
user_story: "**As a** Developer,\n**I want** to set up a local Docker-based development infrastructure with PostgreSQL and Redis,\n**So that** I can demonstrate the complete FloDoc system to management without cloud costs or complexity.",
|
|
background: "Before investing in production AWS infrastructure, we need a working demonstration environment that:\n- Can be started with a single command\n- Requires no cloud costs or complex setup\n- Accurately represents the production architecture\n- Allows management to validate the 3-portal cohort management system\n- Can be used for UAT and stakeholder demonstrations\n\nThis story establishes the foundation using Docker Compose, which provides the same architecture as production (PostgreSQL + Redis + Rails app) but runs entirely on a local machine or demo server.",
|
|
acceptance: "**Infrastructure:**\n1. ✅ Docker Compose file created with all services\n2. ✅ PostgreSQL container running and accessible\n3. ✅ Redis container running and accessible\n4. ✅ Minio (S3-compatible) container running\n5. ✅ MailHog container running for email testing\n6. ✅ Rails app container running on port 3000\n7. ✅ Sidekiq container running for background jobs\n\n**Configuration:**\n1. ✅ Database configuration for development\n2. ✅ Redis configuration for development\n3. ✅ Storage configuration for Minio\n4. ✅ Email configuration for MailHog\n5. ✅ Environment variables properly set\n6. ✅ Secrets configured for development\n\n**Automation:**\n1. ✅ Setup script automates initialization\n2. ✅ Teardown script stops and cleans up\n3. ✅ Health check script verifies services\n4. ✅ All scripts executable and documented\n\n**Functionality:**\n1. ✅ Application starts successfully\n2. ✅ Database migrations run\n3. ✅ Seed data can be loaded\n4. ✅ File uploads work (via Minio)\n5. ✅ Emails captured by MailHog\n6. ✅ Background jobs process via Sidekiq\n7. ✅ All three portals accessible\n\n**Documentation:**\n1. ✅ README with setup instructions\n2. ✅ Quick start guide\n3. ✅ Management demo script",
|
|
},
|
|
{
|
|
number: "8.0.1",
|
|
title: "Management Demo Readiness & Validation",
|
|
user_story: "**As a** Product Manager,\n**I want** to validate the complete 3-portal cohort management workflow end-to-end,\n**So that** I can demonstrate FloDoc v3 to management with confidence and real data.",
|
|
background: "After setting up the local Docker infrastructure (Story 8.0), we need to:\n- Test the complete 3-portal workflow with real data\n- Validate all acceptance criteria from previous stories\n- Create a polished demo script for management\n- Ensure the system is production-ready for demonstration\n- Identify and fix any remaining issues before stakeholder review\n\nThis story focuses on **using** the system, not building it. We\'ll create sample cohorts, enroll students, complete signatures, and verify the entire flow works as designed.",
|
|
acceptance: "**Functional:**\n1. ✅ Complete 3-portal workflow tested end-to-end\n2. ✅ Sample cohort with 5+ students created\n3. ✅ All students complete their signing workflow\n4. ✅ Sponsor successfully signs once for entire cohort\n5. ✅ Excel export generates valid file with all data\n6. ✅ All documents signed and stored correctly\n\n**UI/UX:**\n1. ✅ All three portals render correctly\n2. ✅ Progressive disclosure works as designed\n3. ✅ Tab navigation functions properly\n4. ✅ Design system compliance verified\n5. ✅ Mobile responsiveness tested\n\n**Integration:**\n1. ✅ Sidekiq processes all background jobs\n2. ✅ Minio stores all uploaded files\n3. ✅ MailHog captures all emails\n4. ✅ PostgreSQL maintains correct data state\n5. ✅ Redis caching works properly\n\n**Quality:**\n1. ✅ No critical bugs blocking demo\n2. ✅ Performance acceptable (< 2s page loads)\n3. ✅ Error handling graceful\n4. ✅ Data integrity verified\n\n**Demo Readiness:**\n1. ✅ Demo script created and tested\n2. ✅ Management can access all portals\n3. ✅ Sample data is realistic and compelling\n4. ✅ All stakeholders can complete their tasks",
|
|
},
|
|
{
|
|
number: "8.5",
|
|
title: "User Communication & Training Materials",
|
|
user_story: "**As a** Training Provider (TP Admin),\n**I want** clear guidance on using FloDoc\'s 3-portal system,\n**So that** I can manage cohorts effectively without confusion.",
|
|
background: "Existing DocuSeal users need to understand:\n- What changed (3-portal workflow)\n- How to use new features (cohort management)\n- Where to get help (support channels)\n- What\'s different (ad-hoc student/sponsor access)\n\nWithout this communication, adoption will suffer and support will be overwhelmed. This story addresses PO Validation Issue #3 (User Communication & Training Plan Missing).\n\n**Key Deliverables:**\n1. Migration announcement for existing users\n2. TP Portal \"Getting Started\" guide\n3. Student Portal onboarding tutorial\n4. Sponsor Portal quick-start guide\n5. FAQ with 20 common questions\n6. Support contact process",
|
|
acceptance: "**Functional:**\n1. ✅ Migration announcement email sent to all existing DocuSeal users\n2. ✅ TP Portal \"Getting Started\" guide created (5 steps)\n3. ✅ Student Portal onboarding tutorial (3 steps, mobile-friendly)\n4. ✅ Sponsor Portal quick-start guide (bulk signing focus)\n5. ✅ FAQ document with 20 common questions\n6. ✅ Support contact process defined\n7. ✅ Help overlay on first login for TP Portal\n8. ✅ Help button accessible on all major screens\n9. ✅ Error messages link to contextual help\n\n**UI/UX:**\n1. ✅ Help buttons visible in all portals\n2. ✅ Tutorial tooltips on first login\n3. ✅ Mobile-responsive documentation\n4. ✅ Consistent help iconography\n\n**Integration:**\n1. ✅ Email templates integrate with existing Devise mailer\n2. ✅ Help content served via `/help` routes\n3. ✅ Error help displays in all portals\n\n**Security:**\n1. ✅ No sensitive data in documentation\n2. ✅ Token links in emails are single-use\n3. ✅ Help pages don\'t expose internal URLs\n\n**Quality:**\n1. ✅ All documentation reviewed by PO\n2. ✅ No spelling/grammar errors\n3. ✅ Consistent branding and tone\n4. ✅ Links verified and working",
|
|
},
|
|
{
|
|
number: "8.6",
|
|
title: "In-App User Documentation & Help System",
|
|
user_story: "**As a** User (TP Admin, Student, or Sponsor),\n**I want** contextual help and documentation,\n**So that** I can solve problems without contacting support.",
|
|
background: "Deferred to post-MVP per PO validation. This story adds in-app help system after core functionality is validated.\n\n**Note**: This story is deferred pending successful MVP validation.",
|
|
acceptance: "Not found",
|
|
},
|
|
{
|
|
number: "8.7",
|
|
title: "Knowledge Transfer & Operations Documentation",
|
|
user_story: "**As a** Support/Operations Team,\n**I want** comprehensive runbooks and documentation,\n**So that** I can support FloDoc without ad-hoc knowledge transfer.",
|
|
background: "Deferred to post-MVP per PO validation. This story creates operations documentation after system is proven.\n\n**Note**: This story is deferred pending successful MVP validation.",
|
|
acceptance: "Not found",
|
|
},
|
|
];
|
|
if (document.readyState === "loading") {
|
|
document.addEventListener("DOMContentLoaded", () => {
|
|
stories.push(...storiesData);
|
|
initializeSlides();
|
|
});
|
|
} else {
|
|
stories.push(...storiesData);
|
|
initializeSlides();
|
|
}
|
|
</script>
|
|
</body>
|
|
</html> |