# Schoolhouse ERP 0.2.1 — functional acceptance report Test date: 5 October 2026 (Asia/Kolkata). All records, accounts, payments and documents used for testing were fictional. No bank transfers, messages to parents or live school records were involved. ## Result and evidence The implemented first-iteration workflows passed the automated and browser checks below after the defects found during testing were fixed. This is evidence for the scenarios exercised, not a guarantee that every possible input, device or deployment is defect-free. | Verification layer | Result | Environment / evidence | | ----------------------------------------- | ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Automated domain, HTTP and recovery tests | 68 passed, 0 failed | Node 26 on macOS; real temporary SQLite databases and actual local HTTP services. Includes 10 original domain tests, 1 original HTTP integration test, AC01–AC24, AC25 process-crash recovery RC01–RC15 result configuration tests and SEC01–SEC17 security/durability tests. | | Browser acceptance | 60 original + 15 result + 9 security assertions passed | Actual UI interactions against a separate fictional school at localhost:4318. Includes files saved to disk, backup restore, role changes and negative cases. These were interactive checks, not a repeatable automated browser suite. | | Embedded desktop runtime smoke test | 8 checks passed | Electron 44.5.1 / embedded Node 24.21.0, macOS arm64. Fresh setup, SQLite, payment, result scheme/template/CSV, backup, restart, restore and integrity check. | | Native Windows acceptance | Pending | The Windows x64 ZIP is cross-built on macOS. Windows launch, OS dialogs and physical printing require a Windows machine. A verification script is included in the ZIP. | Machine-readable test logs and the runtime smoke report are saved under `test-results/` in the source workspace. The Windows package includes a copy of this report. Browser console inspection at the end of the acceptance run returned no errors. ## Implemented and tested features “UI” refers to browser interaction and inspection of the resulting state/document. “API” refers to an automated request through the actual HTTP service. Printed document content was checked on screen; physical paper output and native print dialogs were not exercised. | Feature area | Implemented scope | What passed | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | School / group configuration | School name, short name, identity, campuses, class/section groups, subjects, active academic year, receipt prefix, currency, grading scale and default leave allowance | UI changed school identity/year and added a class; campus switching isolated rosters. API saved/reloaded configuration, rejected invalid grades, protected existing financial currency and campuses assigned to active users. AC01, AC19–20; UI39–41. | | Students and guardians | Create/edit profiles, guardian/contact/address details, admission numbers, class/section, status, notes, search, document attachments, CSV import/export, year filters and individual year/class movement | UI enquiry enrolment, student edit, search, two-row import, actual CSV download, year movement and preserved fee ledger/attachments. API duplicate numbers, stale edits, status changes, restart persistence and 500-row import. AC02, AC22; UI03–07, UI41, UI55, UI57. | | Student attendance | Daily class registers, Present/Absent/Late/Leave, notes, bulk saving, corrections and attendance totals | UI mixed present/absent register and totals. API all statuses, corrections, future-date/campus validation, atomic rejection of an invalid batch and stale-window conflict. AC04, AC23; UI08, UI37. | | Fees and receipts | Individual invoices, concessions/reasons, partial/full collection, Cash/Bank transfer/UPI/Cheque/Card, references, numbered receipts, outstanding balances, authorized reversals and CSV ledger | UI ₹1,000 invoice less ₹100 concession, ₹300 UPI collection, ₹600 balance, reversal back to ₹900, then ₹900 cash settlement. Receipt/report values checked. API all five methods, receipt snapshots, overpayment rejection and concurrent/idempotent request handling. AC05–06; UI09–14, UI37. | | Communication | Draft/published announcements, class/audience labels, priority, publication date, attachments, staff noticeboard and printable circular | UI draft creation, publication and circular document. API edit/delete and draft visibility for read-only staff; attachment routes enforce visibility. AC07, AC16; UI15–16, UI52–54. This is internal communication, without external delivery. | | Homework / classwork | Assignments by class/subject/teacher, instructions, deadlines, maximum marks, attachments, submission status, marks and feedback entered by staff | UI submission graded 8.5/10 and feedback retained. API teacher workflow, out-of-range mark rejection, protection against changing maximum marks after submissions and persistence across restart. AC08, AC16; UI17–18. | | Timetable and substitutions | Class/teacher/room periods, weekday/time scheduling, conflict checks, date-specific substitute teacher and printable timetable | UI saved period, rejected duplicate conflict, assigned substitute and rendered timetable. API teacher/class/room conflicts, duplicate substitutions, deletion rules and prevention of moving an already-substituted period. AC09 and original domain conflict test; UI19–22. | | Staff and leave | Staff directory, employee numbers, designation, joining date, salary base, staff attendance, leave request/approve/reject, overlap checks and paid leave allowance | UI staff creation, attendance, approved two-day leave, blocked excess allowance and rejection. API all attendance statuses, overlapping requests, final-decision locking, paid/unpaid balance treatment and invalid batches. AC04, AC11; UI28–32. | | Dashboard and reports | Campus totals, daily attendance, collection trends, class dues, payment-method totals, audit activity, CSV exports and printable reports | UI dashboard and reports reconciled against collected fees/attendance, excluded reversed UPI payment, and rendered report document. API role/campus export access and heterogeneous CSV fields. AC05, AC14, AC21; UI07, UI37–39. | | Exams and report cards | Assessment/class/subjects, marks entry, maximum/pass marks, remarks, completeness checks, publication, reopening, grade scale and frozen printable report cards | UI blocked incomplete publication, saved marks and published after correction, verified 160/200 = 80% grade A, reopened/corrected/republished to 170/200. API score limits, immutable published snapshots, duplicate-publication rejection and stale editor conflicts. AC10, AC24; UI23–27. | | Admissions | Enquiry, Applied, Review, Offered, Declined and Enrolled stages; guardian details, source, follow-up, documents and enrolment into students | UI created enquiry and enrolled an offered applicant. API tested enquiry → application → review → offer → enrolment, blocked premature/duplicate enrolment and retained application documents on the admission record. AC03; UI01–03. | | Certificates and ID | Numbered Student ID, Bonafide, Transfer and Character templates, purpose/signatory/date, saved school/student details and printable document views | All four document views generated in UI. API checked unique numbers, snapshot stability after student edits and rejection of edits to issued documents. AC13; four UI36 assertions. IDs use initials rather than photos. | | Payroll | Monthly staff salary base, manually reviewed allowances/deductions/unpaid days, loss-of-pay calculation, net salary, duplicate prevention, payslip and recorded disbursement reference | UI ₹31,000 + ₹1,000 − ₹500 − ₹1,000 loss of pay = ₹30,500; payslip and paid reference verified. API arithmetic, bounds, duplicate runs, salary snapshots and paid-state protection. AC12; UI33–35. | | Accounts, roles and access | Administrator, principal, accountant, teacher and reception; account creation/disable/enable; campus assignments; password change; logout; session and CSRF checks | UI logged in as all roles and checked navigation; disabled/re-enabled teacher. API checked every module's read/export permission, forbidden writes, cross-campus access, invalid credentials, password-change session invalidation and logout. AC14–15 and original HTTP test; UI42–48. | | Files and CSV | Attachments on students, admissions, notices, homework and submissions; 5 MB each, up to 10 per record; CSV import/export with quoted fields and spreadsheet-formula protection | UI selected/uploaded an attachment, downloaded it after restore and compared bytes with the original. Actual CSV download parsed successfully. API exercised all five attachment owner types, oversized/unknown-campus rejection, formula protection, failed-import rollback and malformed CSV handling. AC16, AC21–22 plus original tests; UI05–07, UI55, UI57. | | Backup and recovery | Verified startup/hourly/shutdown snapshots, configurable destination, newest-30 per-installation retention, encrypted export, authenticated restore, session invalidation, restore onto another installation and local backup path preservation | UI changed destination, created snapshot, exported a real file, authenticated/decrypted it, restored it, verified later changes disappeared, signed back in and downloaded restored attachment. API wrong-passphrase rejection, separate-installation recovery, document integrity and snapshot retention. AC17–18; UI49–57. | | Persistence and concurrent use | SQLite WAL, full synchronous writes, transactions, versioned edits, payment idempotency and atomic batches | API restart persistence and competing collections/edits. A child host was killed with SIGKILL after a committed write; restart recovered the row and passed SQLite integrity checking. This simulates a host-process crash, not physical power failure or disk failure. AC06, AC22–25. | ## Version 0.2: configurable results The previous 60 browser assertions cover the original school workflows. The new result extension has 15 additional successful browser assertions and 15 automated cases (RC01–RC15), bringing the full automated suite to 51 passing tests. | New capability | Evidence | | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Named assessment schemes reusable across years/classes through duplication | UI created a class scheme with 20% / 80% components and per-subject final maximums; rejected weights totaling 110%. | | Calculation rules | RC01–RC03 verify normalization across different exam maximums, weighted marks, per-subject and overall pass rules, grades, decimal precision, rounding modes and invalid/duplicate configuration. Final subject maximums must be whole numbers. | | Named Classic, Compact and Detailed templates | Renderer tests cover all three. UI created a Detailed template with an embedded PNG logo, attendance and signatures, then duplicated it into a Compact template with hidden guardian/component sections. | | Generation and preview | UI mapped 20-mark and 100-mark published assessments for three students. Totals were 119/150 = 79.3% for two students and 127/150 = 84.7% for one. Automated checks reject unpublished exams, mixed years/classes, unequal rosters and incomplete mappings. | | Publication and concurrent changes | Preview fingerprints reject changed configuration, source marks or attendance. Repeated requests are idempotent and duplicate active issues are blocked. Published data includes the school's local issue date. | | Frozen reports and reissue | Editing the saved template left the existing published report unchanged. UI reissued using the Compact template; the old Detailed issue remained Superseded. Automated tests also freeze calculation rules, student details and source marks. | | Individual and whole-class reports | UI rendered the three-student batch and visually inspected an individual Compact report. One student starts per printed page, with continuation pages when needed. Native print/PDF dialogs and physical printing remain pending. | | CSV marksheet | Authenticated API checks validate subject columns, totals and percentages. The Electron runtime check generates the response and writes it to a temporary CSV file. The in-app browser reached the export control but did not expose a download event or confirm a file in Downloads; end-user file-saving acceptance remains pending on the target desktop. | | Backup and access | Automated tests restore schemes, templates and frozen results, verify campus/role restrictions and preserve results when students move year/class. Administrators/principals configure and publish; teachers read issued reports. | Browser checks RUI01–RUI15 cover: weight validation; scheme save; template save; weighted class totals; subject final maximums; attendance/grade/signature sections; embedded logo; class batch; publication; template duplication; snapshot preservation; hidden sections; reissue history; local publication date; visual layout. Browser console inspection returned no errors. Logs: `test-results/results-tests.log`, `test-results/results-ui-acceptance.json`, `test-results/results-runtime-smoke.json`. This release uses structured layouts rather than arbitrary Word/PDF uploads or free-position design. Calculation supports numeric marks, common component weights across subjects and the documented pass/rounding rules. Best-of, absent/exempt codes, grade-only co-scholastic assessment and automated board-specific compliance remain outside scope. Each source assessment has one maximum across its subjects; final subject maximums are configurable in the scheme. ## Defects fixed during this acceptance pass - CSV export now includes fields found in later rows, such as reversal reasons and payment references. CSV import rejects malformed quoting and empty column headers. - Draft/future announcements and their attachments are hidden from staff who have read-only announcement access. - Attendance and marks saved from an older browser window now produce a conflict instead of overwriting a newer correction. The marks grid updates saved versions correctly when publication fails for incomplete marks. - Repeated exam publication cannot replace frozen report details; the exam must be explicitly reopened first. - A timetable period with recorded substitutions cannot silently move to a different schedule. - Attachment upload validates the campus and attachment count. The download button now saves the actual file; restored attachment bytes were verified on disk. - Restoring another installation's backup preserves the destination computer's backup folder. - Configuration cannot reinterpret existing financial records by changing currency or remove a campus still assigned to an active account. - Malformed configuration/batch objects and invalid record references return validation errors instead of server errors; account activation requires a boolean value. - Student and fee screens can filter by academic year or show all years, preserving access when an individual student is moved to the next year. ## Reproduce the checks From the project folder with dependencies installed: ```sh npm run check npm run format:check npm test npm run test:acceptance ``` `npm test` already includes the acceptance and recovery tests. The narrower command is useful when repeating only the expanded acceptance cases. All automated tests use disposable databases; they do not modify an existing school. For browser acceptance, `node tests/ui-fixture.mjs` creates an isolated fictional workspace at `.schoolhouse/acceptance` and serves port 4318. The accounts `admin`, `teacher`, `accountant`, `principal` and `reception` have the password `Schoolhouse2026!`. This fixture retains changes between runs and should never be used as a live school. The tests under `tests/fixtures/` provide a synthetic CSV and attachment. The browser assertions described here were performed interactively; the fixture is not itself a browser test runner. On Windows, extract the entire ZIP and run `Verify-installation.cmd`. It uses the packaged executable and embedded SQLite to test a temporary fictional school, payment, encrypted backup, restart, restore and database integrity, then writes `verification-report.json`. It does not modify the live school. Read the report and then perform the remaining interactive checks below. ## Remaining deployment acceptance These checks are still required on the actual school computer before live use: 1. Launch and close the Windows desktop app; complete fresh setup, then reopen and confirm data persists. Check Windows account/data-folder permissions and the unsigned executable prompt. 2. Save/download/upload files using Windows dialogs. Run the packaged verification script and inspect its report. 3. Print a fee receipt, payslip, each certificate/ID template, report card and timetable using the school's printer or PDF driver; verify paper sizing and readability. 4. Choose a real external backup device, save/restore a copy and check behavior when that device is unavailable. Same-disk snapshots alone do not protect against disk failure. 5. If multiple computers will connect, validate the actual firewall, trusted TLS certificate, host address and a second computer. The acceptance run used local clients; it did not prove the school's LAN setup. 6. Check school-specific grading, receipt/certificate wording, currency, leave policy and payroll deductions against the school's requirements. These are configurable operational inputs, not automatic statutory compliance. The 500-student import check passed, but this is not a large-school load or long-duration soak test. Physical power failure and a real external-drive disconnection remain untested. Version 0.2.1 adds simulated missing folders, injected corrupt backup files and SQLite storage-full/rollback tests; these do not establish behavior for every physical storage failure. There is no claim of native Windows acceptance until it is performed on Windows. ## First-iteration scope boundaries - Internal noticeboard only: no parent/student portal, SMS, WhatsApp, email or push delivery. - Payments and salary disbursements are recorded after external payment; no payment gateway or bank transactions. - Payroll statutory deductions are operator inputs; no tax/PF/ESI filing engine. Leave counts inclusive calendar days. - Individual student year/class movement, with year filters on students and fees; no bulk promotion engine or universal historical-year interface across all modules. - No transport, library, inventory, biometrics, student photo capture or automated inter-branch/offline synchronization. - One installation is one school/group. Campuses share its configuration. There is no SaaS tenant provisioning, licensing/activation, signed installer, background Windows service or updater. - No load certification or promise of zero defects. The native Windows and school deployment checks above remain open. ## Security and durability update — 0.2.1 The current full suite passes **68 tests**, including 17 new security/durability cases. The 51-test result in the configurable-results section describes the earlier 0.2.0 feature acceptance run. This release fixes Windows static-file containment, requires TLS for LAN listeners, authenticates before buffering uploads, bounds request sizes and persists per-account/client login throttling. Backup verification, installation-specific retention, disconnected-folder warnings, local fallbacks, shutdown snapshots and atomic restore bookkeeping are now implemented. Account changes and attachment uploads also commit their audit entries atomically. Startup refuses corrupt/empty/orphaned recovery databases. Nine additional interactive backup checks passed in the fictional browser workspace, using a renamed directory to simulate unavailable storage. The warning remained visible outside the recovery page; five student records stayed available; restoring the directory and backing up again cleared the warning. This does not replace actual Windows/external-device testing. The installed dependency audit returned zero known vulnerabilities. See [Security and recovery review](security-and-recovery.md) for SEC01–SEC17, the limits of these tests, unencrypted local storage, the hourly recovery window and required deployment checks. Logs are in `test-results/security-tests.log`, `security-ui-acceptance.json`, `security-dependency-audit.json` and `security-packaged-smoke.json`.