System Requirements Document for academic-assistant-coursework

1. Introduction

This document specifies Homework Buddee, a persistent autonomous academic assistant built inside the user's 8080.ai account. Homework Buddee is not a generic chatbot and not a build guide: it is a configured, tested agent that behaves like an academic worker for a single motivated online learner. It reads course material, reads rubrics, researches, writes, cites, formats documents, navigates educational websites through browser automation, learns the student's writing voice, absorbs instructor feedback, and maintains course progress across sessions.

The product intent is a split-brain craft tool: one half reads the lesson and enforces the rubric; the other half writes the paper in the student's own voice. The audience is one student working at a browser all day across essay-heavy online courses (Sophia Learning, U.S. Government, and comparable coursework), who wants quiet competence and auditable proof that verification actually happened — not a friendly study app and not an enterprise dashboard.

The delivery is browser-based daily operation, native-first, persistent, low-cost, with minimal command-line administration and few external services.

2. System Overview

Homework Buddee is delivered as a first-party application surface set inside the student's 8080.ai environment, backed by the 8080.ai agent runtime, persistent memory, browser/computer-use system, document tooling, and research tooling. The student signs in, configures the agent once, and thereafter opens Homework Buddee and speaks an objective (for example, "Continue my U.S. Government course. Read the current lesson and help me work through it."). The agent determines context, reads permitted materials, maintains course context, researches when needed, assists with coursework, creates required documents, applies instructor feedback, verifies its work, and maintains progress without rebuilding the setup each session.

Actors. The closed active-human catalog contains exactly two personas: the Student / Coursework Owner (the human account owner and coursework owner) and the Homework Buddee Academic Agent (the persistent autonomous assistant being built and operated). External educational sites (Sophia Learning and other course platforms), the 8080.ai provider runtime, and research sources are typed non-persona actors and providers, not personas.

Accepted behavior. Capability mapping against the actual 8080.ai environment; persistent agent profile and core identity instructions; structured persistent memory in four scopes; the 12-step academic workflow; course-material priority; research standards; citation support and verification; writing-style learning; instructor-feedback learning; document creation and reading; browser/computer use with ten reliability rules; the Sophia Learning workflow; the question workflow; self-improvement; the reusable homework-buddee-academic-workflow skill; confirmation gates for consequential actions; and end-to-end capability testing with VERIFIED status only after successful testing.

Ownership. The student owns all coursework, authorizes consequential actions, and supplies materials, samples, and feedback. Homework Buddee performs the reading, research, drafting, verification, and reporting. External educational platforms own their own authentication, assessment security, and proctoring. The 8080.ai provider owns the runtime, model access, browser/computer-use system, and persistence substrate.

Narrow exclusions. Homework Buddee does not bypass CAPTCHA, MFA, authentication, access controls, anti-bot protections, or proctoring; it pauses for the student when human verification is required. It does not store passwords, private keys, API keys, tokens, or unnecessary secrets. It does not fabricate sources, authors, quotations, URLs, DOI numbers, page numbers, publication dates, or citations. It does not silently replace course content with general AI knowledge. It does not report success without verification. Where outside AI assistance is prohibited for an assessment, it switches to tutoring, explanation, review, practice, and study assistance rather than assisting with the assessment.

2a. Product Interpretation and Delivery Boundary

Homework Buddee is delivered as a first-party browser-based workspace that the student signs into, plus provider-managed surfaces where 8080.ai owns the underlying capability (model runtime, browser/computer-use system, document generation, research retrieval, persistent storage). The student's daily workflow is browser-based: open the workspace, speak an objective, watch the agent work, review the proof strip, and authorize anything consequential.

Identity and access. The student establishes application identity through Login before reaching protected configuration, memory, coursework state, generated documents, and testing. Landing is the anonymous public entry that explains Homework Buddee, its student audience, the academic workflow, and persistent browser-based assistance before sign-in. Login is the returning-verification boundary; it does not own account creation, password reset, or adjacent account-management capabilities, which are not accepted scope.

Credentials for external educational sites. Where external educational-site credentials are required, the student enters them through secure provider or browser mechanisms. Secrets are never pasted into chat and never stored in memory.

Human verification. CAPTCHA, MFA, authentication challenges, access-control events, and proctoring require the student's participation. The agent pauses and hands control back.

Current vs. future. Everything specified in this document is current scope. No future-horizon requirements were accepted in the authoritative thread; the "future ideas" surface is empty by source.

2b. Source Content Inventory

No reference directive in this project declares content_source authority. No source content inventory is included.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous first impression. Explains what Homework Buddee is (a persistent autonomous academic assistant for coursework, online learning, research, writing, studying, permitted coursework questions, citations, files, document creation, browser navigation, instructor feedback, and course-progress memory), who it is for (a single motivated online learner working at a browser all day), and how it works (the 12-step academic workflow, course-material priority, verification, and persistent memory). States the hard boundaries: no bypassing CAPTCHA/MFA/authentication/access controls/anti-bot protections/proctoring; no fabricated sources or citations; no stored secrets.
• Primary action: Proceed to Login.
• Supporting actions: Read the workflow explanation; read the boundary/exclusion statements; read the capability summary.
• Domain entities: Homework Buddee agent identity; the 12-step academic workflow; the four memory scopes (Global / Course / Assignment / Feedback); the nine tool pictograms (browser, document, citation, memory, research, feedback, rubric, file, skill).
• Component responsibilities: Hero split (58% warm paper / 42% dark ink) with the three-line Fraunces headline "READ THE LESSON. / WRITE THE PAPER. / SHOW YOUR WORK."; a live mono rubric checklist with two ticked criteria; a terminal-like activity log panel in JetBrains Mono; a single accent-underlined line beneath the headline; the one primary CTA.
• States: Loading — static content, no async dependency. Empty — not applicable (static entry). Success — content renders; CTA routes to Login. Error — if the CTA route fails, an inline mono error line with a retry. Recovery — retry the CTA; the page remains readable.

Login

• Information/state: Returning-verification surface. Confirms the student's identity so persistent Homework Buddee configuration, memory, coursework state, and generated work can be resumed. Does not own account creation, password reset, or adjacent account-management capabilities.
• Primary action: Verify identity and enter the protected workspace.
• Supporting actions: Return to Landing; read the access-boundary statement.
• Domain entities: Student identity; session continuity.
• Component responsibilities: Identity verification form; inline validation; access-boundary note; link back to Landing.
• States: Loading — verification in progress with a restrained indicator. Empty — not applicable. Success — route to Dashboard. Error — invalid credentials or verification failure shown inline with a retry; no partial access granted. Recovery — retry verification; if human verification (MFA/CAPTCHA) is required, the student completes it directly.

Dashboard

• Information/state: Authenticated continuation hub. Shows active courses, current assignment, workflow progress (the numbered 01–12 sequence), verification results, agent activity, and the four memory scopes as labelled drawers (Global / Course / Assignment / Feedback). The permanent left ink rail holds the course tree (Course → Unit → Section → Tutorial/Challenge) and the live agent indicator.
• Primary action: Resume the current course/assignment or start a new objective.
• Supporting actions: Navigate to any configuration or capability surface; open a memory drawer; open the current assignment's split-dialog task view.
• Domain entities: Course; Unit; Section; Tutorial/Challenge; Assignment; workflow stage (01–12); agent status; memory scope.
• Component responsibilities: Left ink rail (240px) with course tree and agent chip; paper workspace with 12-column grid; assignment header (32px Fraunces); workflow stage numerals (72px Fraunces); proof strip under completed tasks; split-dialog task view (mono rubric checklist left, draft right).
• States: Loading — skeleton of the course tree and assignment header. Empty — no courses yet: a mono empty state inviting the student to state an objective or add a course. Success — course tree, current assignment, workflow stage, and agent status render. Error — a failed course/memory load shows an inline mono error with retry; the rail remains navigable. Recovery — retry the failed load; the student can still open other surfaces.

Capability Map

• Information/state: The REQUIREMENT -> 8080.AI FEATURE -> NATIVE/EXTERNAL -> CONFIGURATION NEEDED mapping produced by inspecting the actual 8080.ai environment. Each accepted requirement is listed with its mapped feature, whether the feature is native or external, and the configuration still needed.
• Primary action: Confirm the mapping and proceed to build/configure.
• Supporting actions: Filter by native/external; mark a mapping as configured; open the corresponding configuration surface.
• Domain entities: Requirement; 8080.ai feature; native/external classification; configuration item; build order step (1–13).
• Component responsibilities: Mono mapping table; native/external badges; configuration-needed column; build-order sequence (01–13) as editorial numerals; link from each row to its owning surface.
• States: Loading — mapping table skeleton. Empty — inspection not yet run: a mono prompt to run the environment inspection. Success — full mapping renders with build-order sequence. Error — inspection failed: inline mono error with retry and the reason. Recovery — re-run inspection; previously confirmed rows are preserved.

Agent Profile

• Information/state: The persistent Homework Buddee agent/profile identity and its core identity/system instructions. Shows the agent name, mission statement, autonomy policy (high autonomy for harmless and reversible work; ask before consequential or difficult-to-reverse actions), and the boundary statements.
• Primary action: Save the persistent agent profile and core system instructions.
• Supporting actions: Edit identity text; edit autonomy policy; edit boundary statements; preview the assembled system instructions.
• Domain entities: Agent profile; core identity; system instructions; autonomy policy; boundary statement.
• Component responsibilities: Identity editor; system-instruction editor in JetBrains Mono; autonomy-policy control; boundary-statement list; save/verify control; persistence indicator.
• States: Loading — profile skeleton. Empty — no profile yet: a mono prompt to create the persistent Homework Buddee profile. Success — profile saved and persisted; a confirmation line states it survives logout/restart. Error — save failed: inline mono error with retry; unsaved edits retained in the editor. Recovery — retry save; the editor keeps the student's text.

Memory

• Information/state: The four structured persistent memory scopes — Global User Memory (durable writing, formatting, and workflow preferences), Course Memory (course name, terminology, instructor rules, citation style, formatting, feedback, progress), Assignment Memory (current assignment, relevant lesson, rubric checklist, sources, draft state, completed and remaining requirements), and Feedback Memory (student corrections, instructor corrections, recurring mistakes, successful approaches). Also shows the secret-exclusion control: passwords, private keys, API keys, tokens, and unnecessary secrets are never stored.
• Primary action: Store or retrieve a memory entry in the appropriate scope.
• Supporting actions: Add/edit/remove an entry; run a harmless-preference store-and-retrieve demonstration; inspect the secret-exclusion state.
• Domain entities: Memory scope (Global / Course / Assignment / Feedback); memory entry; memory key; secret-exclusion rule.
• Component responsibilities: Four labelled drawers in the left ink rail; mono memory-key list; entry editor; retrieval demonstration panel; secret-exclusion indicator.
• States: Loading — drawer skeletons. Empty — a scope with no entries shows a mono empty state. Success — entry stored and later retrieved with a visible retrieval proof. Error — store or retrieve failed: inline mono error with retry. Recovery — retry; if a secret was detected, the entry is rejected with an explicit mono reason and the secret is not persisted.

Workflow

• Information/state: The complete course-material-first academic workflow, rendered as the numbered 01–12 sequence: 01 Identify the course, unit/module, section, lesson/tutorial, and assignment; 02 Read the relevant course material; 03 Read the complete instructions and rubric; 04 Inspect required readings, examples, instructor comments, uploaded files, formatting rules, citation requirements, and relevant prior work; 05 Build an internal checklist of every requirement; 06 Complete the work; 07 Verify facts and citations; 08 Compare the result against every rubric criterion; 09 Check every question/sub-question; 10 Check formatting and required deliverables; 11 Perform final quality control; 12 Give a concise completion report.
• Primary action: Run the workflow for the current objective.
• Supporting actions: Jump to a stage; open the split-dialog task view; open the proof strip for a completed stage; hand off to Research, Documents, Browser, Sophia, Writing Style, Feedback, or Quality Control.
• Domain entities: Workflow stage (01–12); requirement checklist item; rubric criterion; question/sub-question; deliverable; completion report.
• Component responsibilities: Editorial stage numerals (72px Fraunces); mono requirement checklist with 180ms left-to-right wipe and 1px accent underline per verified line; split-dialog task view (rubric left, draft right, same scroll position); proof strip; completion-report panel.
• States: Loading — stage skeleton with the current stage marked. Empty — no active objective: a mono prompt to state one. Success — each stage completes in order with visible verification; the completion report renders. Error — a stage fails: the workflow halts at that stage with an inline mono error, the reason, and the last verified state. Recovery — re-inspect and retry the failed stage; the workflow resumes from the last verified stage without redoing verified work.

Research

• Information/state: Source research, source-priority policy (primary sources, government sources, universities, peer-reviewed scholarship, scholarly publications, official institutions, established research organizations, and high-quality journalism where appropriate), claim verification, citation-style selection (MLA, APA, Chicago, and instructor-specific formats), and the correspondence check between in-text citations and References/Works Cited.
• Primary action: Retrieve and verify a real source for the current claim.
• Supporting actions: Select citation style; verify a claim against a retrieved source; check in-text/References correspondence; attach a source to the current assignment.
• Domain entities: Source; source type; claim; citation style; in-text citation; References/Works Cited entry; verification result.
• Component responsibilities: Source list in JetBrains Mono; source-type labels; claim-to-source binding; citation-style selector; correspondence checker; proof strip showing the retrieved URL, page state, and timestamp.
• States: Loading — retrieval in progress with the agent chip pulsing. Empty — no sources yet: a mono empty state. Success — source retrieved, claim verified, citation rendered in the required style. Error — retrieval or verification failed: inline mono error with the reason; no citation is emitted for an unverified source. Recovery — retry retrieval; if a source cannot be verified, it is excluded and the student is told.

Documents

• Information/state: Reading of supported coursework files and creation of DOCX, PDF, PPTX, XLSX/CSV, research notes, study guides, outlines, and bibliographies. Shows the exact assignment formatting rules in force: font, size, margins, spacing, headers, page numbers, indentation, headings, citations, filename, and file type. Shows whether the current deliverable is a draft or a submission-ready deliverable.
• Primary action: Create or read a document.
• Supporting actions: Read a test document; create a test document; set formatting rules; set filename and file type; mark as draft or submission-ready.
• Domain entities: Document; file type; formatting rule; filename; draft state; deliverable.
• Component responsibilities: File list in JetBrains Mono; formatting-rule panel; document preview; create/read controls; draft/submission-ready toggle; proof strip with the file path and timestamp.
• States: Loading — file list skeleton. Empty — no documents yet: a mono empty state. Success — document created or read; formatting rules applied; the deliverable is submission-ready unless the student requested a draft. Error — creation or read failed: inline mono error with the reason and the unsupported-format note where applicable. Recovery — retry; if a format is unsupported, the student is told and offered a supported alternative.

Browser

• Information/state: The verified semantic browser and computer-use operations for permitted educational navigation and reading: navigate educational websites, read lessons, inspect questions and choices, scroll, click permitted controls, enter permitted information, move between sections, inspect files, and verify actions. Displays the ten browser reliability rules as an enforced checklist: 01 Inspect the page before acting; 02 Prefer semantic controls/DOM data (accessible roles, labels, button names, link text, visible text, stable attributes); 03 Avoid fragile coordinate clicking when semantic controls exist; 04 Wait for dynamic content to become visible/actionable; 05 Scroll targets into view; 06 Detect overlays, dialogs, cookie notices, and pop-ups; 07 Verify intended selections/input before proceeding; 08 Verify the expected page/state change after actions; 09 If an action fails, inspect the page again instead of blindly repeating clicks; 10 Never report success without verification.
• Primary action: Run a browser operation against a permitted educational page.
• Supporting actions: Run a harmless navigation/read test; inspect the current page state; open the proof strip for the last operation.
• Domain entities: Browser session; page; semantic control; overlay/dialog/cookie notice/pop-up; page state change; verification result.
• Component responsibilities: Browser frame (cropped, desaturated monochrome, single accent highlight on the element that was read); reliability-rule checklist in mono; page-state inspector; proof strip with URL, page state, and timestamp; human-verification pause banner.
• States: Loading — navigation in progress with the agent chip pulsing. Empty — no session yet: a mono prompt to start a permitted navigation. Success — the operation completes and the expected page/state change is verified. Error — the operation failed: the page is re-inspected, the failure reason is shown inline, and no success is reported. Recovery — re-inspect and retry; if CAPTCHA, MFA, authentication, access control, anti-bot protection, or proctoring is encountered, the agent pauses and hands control to the student.

Sophia

• Information/state: Sophia Learning course context: COURSE → UNIT → SECTION → TUTORIAL/CHALLENGE. Shows the relevant Sophia tutorial content, Sophia terminology and conceptual framing, major concepts, Terms to Know, summaries, and relevant lesson content, plus the retained context that avoids rereading everything unnecessarily. Shows the assistance-permission state: when assistance is permitted, Sophia material is the primary source; when outside AI assistance is prohibited for an assessment, the mode switches to tutoring, explanation, review, practice, and study assistance.
• Primary action: Read the relevant Sophia tutorial and maintain course context.
• Supporting actions: Navigate the COURSE → UNIT → SECTION → TUTORIAL/CHALLENGE tree; capture Terms to Know; capture major concepts and summaries; switch to tutoring/review/practice mode when assistance is prohibited.
• Domain entities: Sophia course; unit; section; tutorial/challenge; Terms to Know; major concept; summary; assistance-permission state.
• Component responsibilities: Course tree in the left ink rail; tutorial reader; Terms to Know list in mono; concept/summary panel; assistance-mode indicator; proof strip with the tutorial URL and timestamp.
• States: Loading — tutorial reader skeleton. Empty — no Sophia course yet: a mono prompt to identify the course. Success — tutorial read, terminology and concepts captured, context retained. Error — read failed: inline mono error with the reason. Recovery — retry; if assistance is prohibited for the assessment, the mode switches to tutoring/review/practice and the assessment is not assisted.

Writing Style

• Information/state: The student's writing characteristics learned from samples and corrections: vocabulary, sentence structure, paragraph length, tone, organization, transitions, formality, argument structure, use of evidence, and conclusions. Shows the improvement policy: improve clarity, grammar, organization, evidence, and compliance without converting the work into generic AI prose.
• Primary action: Capture a writing sample or correction and derive the style profile.
• Supporting actions: Add a sample; add a correction; inspect the derived characteristics; preview the style profile applied to a passage.
• Domain entities: Writing sample; correction; style characteristic; style profile.
• Component responsibilities: Sample/correction intake; characteristic list in mono; style-profile preview; proof strip with the sample source and timestamp.
• States: Loading — profile skeleton. Empty — no samples yet: a mono prompt to add a writing sample. Success — style profile derived and applied; the preview reads as the student's voice. Error — derivation failed: inline mono error with the reason. Recovery — retry; the student can add another sample.

Feedback

• Information/state: Instructor and student corrections processed into durable course-specific rules. Shows the five-step instructor-feedback process: 01 Determine what the instructor wanted changed; 02 Correct the current issue; 03 Identify the underlying rule/preference; 04 Store it in course memory when appropriate; 05 Apply it to future work for that course. Shows the no-repeat rule: do not repeatedly make a mistake already corrected. Shows the self-improvement classification: factual, course-context, research, citation, writing-style, formatting, rubric, browser-navigation, tool-use, or instruction-following.
• Primary action: Process a correction into a durable rule.
• Supporting actions: Classify the correction cause; store the rule in Course Memory; apply the rule to future work; inspect recurring mistakes and successful approaches.
• Domain entities: Correction; instructor feedback; underlying rule/preference; recurring mistake; successful approach; correction cause.
• Component responsibilities: Correction intake; five-step process checklist in mono; cause classifier; rule store; recurrence list; proof strip with the correction source and timestamp.
• States: Loading — feedback list skeleton. Empty — no corrections yet: a mono empty state. Success — correction processed, rule stored, and applied to future work. Error — processing failed: inline mono error with the reason. Recovery — retry; the correction text is retained.

Quality Control

• Information/state: The final verification surface: rubric comparison against every criterion, every question/sub-question check, formatting and required-deliverable check, fact and citation verification, and the final quality-control gate before declaring completion. Shows the completion-report output.
• Primary action: Run final quality control and produce the concise completion report.
• Supporting actions: Re-run a failed check; open the proof strip; open the completion report.
• Domain entities: Rubric criterion; question/sub-question; formatting rule; deliverable; fact check; citation check; completion report.
• Component responsibilities: Rubric checklist in mono with 180ms wipe and 1px accent underline per verified criterion; question/sub-question checklist; formatting/deliverable checklist; fact/citation checklist; completion-report panel; proof strip.
• States: Loading — checklist skeleton. Empty — no active deliverable: a mono prompt to select one. Success — every criterion verified; the completion report renders. Error — a criterion fails: the failing line is marked, the reason is shown inline, and completion is not declared. Recovery — fix and re-run the failed check; verified lines remain verified.

Confirmations

• Information/state: The approval gates for consequential or difficult-to-reverse actions: final submission, sending communications, purchases, deleting important information, and changing important account settings. Shows the autonomy policy in force: high autonomy for harmless and reversible work; obvious intermediate steps performed without repeatedly asking permission.
• Primary action: Approve or decline a pending consequential action.
• Supporting actions: Inspect the action's exact scope; inspect the proof strip for the action; decline and return to the workflow.
• Domain entities: Consequential action; action category; approval decision; autonomy policy.
• Component responsibilities: Pending-action list in mono; action-scope detail; approve/decline controls; autonomy-policy note; proof strip.
• States: Loading — pending-action skeleton. Empty — no pending actions: a mono empty state. Success — the student's decision is recorded and the action proceeds or is cancelled. Error — the action failed after approval: inline mono error with the reason. Recovery — retry or cancel; no consequential action proceeds without an explicit approval.

Skills

• Information/state: The reusable custom skill/workflow named homework-buddee-academic-workflow, which enforces the academic workflow, course-material priority, research standards, citation verification, writing-style preservation, instructor-feedback learning, rubric verification, browser reliability, progress tracking, and final quality control. Also shows the 8080.ai equivalents found or created for: Academic Research, Citation Management, Student/Coursework Assistant, Browser Agent, College Exam/Study Preparation, Document/presentation creation, Persistent memory, Web research, File/PDF/document tools, Knowledge bases, API/tool integrations, and persistent browser sessions if available.
• Primary action: Create or update the homework-buddee-academic-workflow skill.
• Supporting actions: Inspect the enforced rules; inspect the tool-equivalent list; edit the skill when 8080.ai supports editable skills/workflows/memory.
• Domain entities: Skill; workflow; enforced rule; tool equivalent; editability state.
• Component responsibilities: Skill editor in JetBrains Mono; enforced-rule list; tool-equivalent list; editability indicator; proof strip with the skill version and timestamp.
• States: Loading — skill skeleton. Empty — skill not yet created: a mono prompt to create it. Success — skill created and persisted; enforced rules listed. Error — creation failed: inline mono error with the reason. Recovery — retry; if 8080.ai does not support editable skills, the student is told and the equivalent memory/workflow component is improved instead.

Testing

• Information/state: The capability demonstrations and their VERIFIED status. Shows the required tests: a harmless browser navigation/read test; a harmless-preference store-and-retrieve memory demonstration if supported; a test-document read; a test-document creation; and a real-source retrieval and citation. Shows the rule: mark capabilities VERIFIED only after successful testing; test, do not assume.
• Primary action: Run a capability test.
• Supporting actions: Re-run a failed test; inspect the proof strip for a test; inspect the end-to-end test result.
• Domain entities: Capability; test; test result; VERIFIED status; proof strip.
• Component responsibilities: Test list in mono; per-test status; proof strip with URL, page state, source, and timestamp; end-to-end test panel.
• States: Loading — test list skeleton. Empty — no tests run yet: a mono prompt to run the first test. Success — the test passes and the capability is marked VERIFIED. Error — the test fails: the capability is not marked VERIFIED, the reason is shown inline. Recovery — re-run the test; VERIFIED status is only granted after a successful run.

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance.

FR-01 — Build Homework Buddee inside 8080.ai. As the Student / Coursework Owner, I should have Homework Buddee actually built inside my 8080.ai account, not merely explained. Provenance: explicit. Trigger: the student starts the build. Observable result: a persistent Homework Buddee agent/profile exists in the account. Failure/recovery: if the build fails, the reason is shown and the build is retried. Continuation: the student proceeds to capability mapping. Access: login.

FR-02 — Inspect the actual 8080.ai environment and map requirements. As the Student / Coursework Owner, I should see each requirement mapped to an actual 8080.ai feature as REQUIREMENT -> 8080.AI FEATURE -> NATIVE/EXTERNAL -> CONFIGURATION NEEDED before building. Provenance: explicit. Trigger: the student starts the build. Observable result: a complete mapping is produced from the actual environment. Failure/recovery: if inspection fails, the reason is shown and inspection is retried. Continuation: the build proceeds in the specified order. Access: login.

FR-03 — Do not stop after the capability map. As the Student / Coursework Owner, I should have the build continue past the capability map and past recommendations. Provenance: explicit. Trigger: the mapping completes. Observable result: the build proceeds through the ordered build steps. Failure/recovery: if the build halts, the student is told where and why. Continuation: the build resumes from the halted step. Access: login.

FR-04 — Configure the agent with the student and test each major capability. As the Student / Coursework Owner, I should configure Homework Buddee with the agent and test each major capability. Provenance: explicit. Trigger: the build reaches configuration. Observable result: configuration is applied and each major capability is tested. Failure/recovery: a failed test is reported and re-run. Continuation: the next capability is tested. Access: login.

FR-05 — Mark capabilities VERIFIED only after successful testing. As the Student / Coursework Owner, I should see a capability marked VERIFIED only after it has been successfully tested. Provenance: explicit. Trigger: a capability test runs. Observable result: VERIFIED status appears only on a successful test. Failure/recovery: a failed test leaves the capability unverified with the reason shown. Continuation: the test is re-run. Access: login.

FR-06 — Prefer native, persistent, reliable, low-cost solutions and a browser-based daily workflow. As the Student / Coursework Owner, I should get native 8080.ai features, persistent solutions, reliable automation, browser-based daily operation, low-cost/free models when adequate, reusable workflows, minimal command-line administration, few external services, settings that survive logout/restart, and easy recovery. Provenance: explicit. Trigger: any build or configuration decision. Observable result: the chosen solution satisfies the preference order. Failure/recovery: if a native option is unavailable, the reason is shown and the closest persistent alternative is used. Continuation: the build proceeds. Access: login.

FR-07 — High autonomy for harmless and reversible work. As the Student / Coursework Owner, I should have Homework Buddee perform obvious intermediate steps without repeatedly asking permission once I give an objective. Provenance: explicit. Trigger: the student states an objective. Observable result: intermediate steps are performed autonomously. Failure/recovery: if a step turns out to be consequential, the agent stops and asks. Continuation: the workflow resumes after the decision. Access: login.

FR-08 — Ask before consequential or difficult-to-reverse actions. As the Student / Coursework Owner, I should be asked before final submission, sending communications, purchases, deleting important information, and changing important account settings. Provenance: explicit. Trigger: a consequential action is reached. Observable result: the action waits for explicit approval. Failure/recovery: a declined action is cancelled and the workflow continues without it. Continuation: the workflow resumes. Access: login.

FR-09 — Follow the 12-step academic workflow. As the Student / Coursework Owner, I should have Homework Buddee follow the 12-step academic workflow for each task: 01 identify the course, unit/module, section, lesson/tutorial, and assignment; 02 read the relevant course material before answering questions based on it; 03 read the complete instructions and rubric; 04 inspect required readings, examples, instructor comments, uploaded files, formatting rules, citation requirements, and relevant prior work; 05 build an internal checklist of every requirement; 06 complete the work; 07 verify facts and citations; 08 compare the result against every rubric criterion; 09 check every question/sub-question; 10 check formatting and required deliverables; 11 perform final quality control before declaring completion; 12 give a concise completion report. Provenance: explicit. Trigger: the student states an objective. Observable result: each stage completes in order with visible verification. Failure/recovery: a failed stage halts the workflow with the reason shown and resumes from the last verified stage. Continuation: the next stage. Access: login.

FR-10 — Course material is the primary authority. As the Student / Coursework Owner, I should have supplied course materials treated as the primary authority for questions about that course, preserving the course's terminology, definitions, conceptual framework, organization, examples, and expected level of detail. Provenance: explicit. Trigger: a course question. Observable result: the answer uses course terminology and framing. Failure/recovery: if course material is unavailable, the agent says so rather than substituting general knowledge. Continuation: the answer proceeds with the limitation stated. Access: login.

FR-11 — Do not silently replace course content; distinguish outside information. As the Student / Coursework Owner, I should never have course content silently replaced with general AI knowledge, and I should see outside information that differs clearly distinguished. Provenance: explicit. Trigger: outside information differs from course material. Observable result: the difference is labeled. Failure/recovery: if the distinction cannot be made, the agent says so. Continuation: the answer proceeds with the distinction. Access: login.

FR-12 — Research source priority. As the Student / Coursework Owner, I should have outside research prioritize primary sources, government sources, universities, peer-reviewed scholarship, scholarly publications, official institutions, established research organizations, and high-quality journalism where appropriate. Provenance: explicit. Trigger: outside research is appropriate. Observable result: sources are drawn from the priority set. Failure/recovery: if no priority source is available, the agent says so and labels the fallback. Continuation: the research proceeds. Access: login.

FR-13 — Verify important claims. As the Student / Coursework Owner, I should have important claims verified. Provenance: explicit. Trigger: an important claim is made. Observable result: the claim is verified against a retrieved source. Failure/recovery: an unverified claim is flagged and not presented as verified. Continuation: the work proceeds with the flag. Access: login.

FR-14 — Never fabricate sources, authors, quotations, URLs, DOI numbers, page numbers, publication dates, or citations. As the Student / Coursework Owner, I should never receive a fabricated source, author, quotation, URL, DOI number, page number, publication date, or citation. Provenance: explicit. Trigger: any citation or source is produced. Observable result: every element traces to a retrieved source. Failure/recovery: an unverifiable element is removed and the removal is stated. Continuation: the citation is rebuilt from verified elements. Access: login.

FR-15 — Support MLA, APA, Chicago, and instructor-specific citation formats. As the Student / Coursework Owner, I should have MLA, APA, Chicago, and instructor-specific citation formats supported, with the required style determined from the assignment. Provenance: explicit. Trigger: a citation is needed. Observable result: the citation renders in the required style. Failure/recovery: if the style cannot be determined, the agent asks. Continuation: the citation is produced. Access: login.

FR-16 — Ensure in-text citations and References/Works Cited correspond. As the Student / Coursework Owner, I should have in-text citations and References/Works Cited correspond. Provenance: explicit. Trigger: a cited deliverable is checked. Observable result: every in-text citation has a matching reference and vice versa. Failure/recovery: a mismatch is flagged and corrected. Continuation: the check re-runs. Access: login.

FR-17 — Verify each cited source actually supports the associated claim. As the Student / Coursework Owner, I should have each cited source verified to actually support the associated claim. Provenance: explicit. Trigger: a citation is attached to a claim. Observable result: the support is verified. Failure/recovery: an unsupported citation is removed or the claim is revised. Continuation: the check re-runs. Access: login.

FR-18 — Learn and preserve the student's writing style. As the Student / Coursework Owner, I should have my writing style learned and preserved from samples and corrections, analyzing vocabulary, sentence structure, paragraph length, tone, organization, transitions, formality, argument structure, use of evidence, and conclusions. Provenance: explicit. Trigger: a sample or correction is provided. Observable result: the style profile is derived and applied. Failure/recovery: if derivation fails, the reason is shown and the sample is retained. Continuation: the profile is applied to the next draft. Access: login.

FR-19 — Improve without converting to generic AI prose. As the Student / Coursework Owner, I should have clarity, grammar, organization, evidence, and compliance improved without my work being converted into generic AI prose. Provenance: explicit. Trigger: a draft is improved. Observable result: the draft reads in the student's voice. Failure/recovery: if the voice drifts, the student's correction is captured. Continuation: the next draft applies the correction. Access: login.

FR-20 — Treat instructor feedback as learning information. As the Student / Coursework Owner, I should have instructor feedback treated as learning information: 01 determine what the instructor wanted changed; 02 correct the current issue; 03 identify the underlying rule/preference; 04 store it in course memory when appropriate; 05 apply it to future work for that course. Provenance: explicit. Trigger: the student provides corrections or graded work. Observable result: the rule is stored and applied. Failure/recovery: if the rule cannot be identified, the agent asks. Continuation: the rule applies to future work. Access: login.

FR-21 — Do not repeatedly make a mistake already corrected. As the Student / Coursework Owner, I should not see a mistake already corrected repeated. Provenance: explicit. Trigger: future work for that course. Observable result: the stored rule is applied. Failure/recovery: a recurrence is flagged and the rule is strengthened. Continuation: the work proceeds. Access: login.

FR-22 — Implement structured persistent memory in four scopes. As the Student / Coursework Owner, I should have structured persistent memory where supported: Global User Memory (durable writing, formatting, and workflow preferences), Course Memory (course name, terminology, instructor rules, citation style, formatting, feedback, progress), Assignment Memory (current assignment, relevant lesson, rubric checklist, sources, draft state, completed and remaining requirements), and Feedback Memory (my corrections, instructor corrections, recurring mistakes, successful approaches). Provenance: explicit. Trigger: a memory-worthy fact arises. Observable result: the fact is stored in the correct scope and retrievable later. Failure/recovery: if memory is unsupported, the student is told and the closest persistent alternative is used. Continuation: retrieval is demonstrated. Access: login.

FR-23 — Do not store passwords, private keys, API keys, tokens, or unnecessary secrets. As the Student / Coursework Owner, I should never have passwords, private keys, API keys, tokens, or unnecessary secrets stored in memory. Provenance: explicit. Trigger: a memory write. Observable result: secrets are rejected and not persisted. Failure/recovery: the rejection is stated with the reason. Continuation: the non-secret part of the entry is stored. Access: login.

FR-24 — Use 8080.ai's strongest appropriate native browser/computer-use system. As the Student / Coursework Owner, I should have Homework Buddee use 8080.ai's strongest appropriate native browser/computer-use system to navigate educational websites, read lessons, inspect questions and choices, scroll, click permitted controls, enter permitted information, move between sections, inspect files, and verify actions. Provenance: explicit. Trigger: a browser operation is needed. Observable result: the operation completes against the permitted page. Failure/recovery: a failed operation is re-inspected and retried. Continuation: the next operation. Access: login.

FR-25 — Follow the ten browser reliability rules. As the Student / Coursework Owner, I should have the ten browser reliability rules enforced: 01 inspect the page before acting; 02 prefer semantic controls/DOM data (accessible roles, labels, button names, link text, visible text, stable attributes); 03 avoid fragile coordinate clicking when semantic controls exist; 04 wait for dynamic content to become visible/actionable; 05 scroll targets into view; 06 detect overlays, dialogs, cookie notices, and pop-ups; 07 verify intended selections/input before proceeding; 08 verify the expected page/state change after actions; 09 if an action fails, inspect the page again instead of blindly repeating clicks; 10 never report success without verification. Provenance: explicit. Trigger: any browser operation. Observable result: each rule is satisfied and visible in the proof strip. Failure/recovery: a violated rule halts the operation and re-inspects. Continuation: the operation resumes. Access: login.

FR-26 — Do not bypass CAPTCHA, MFA, authentication, access controls, anti-bot protections, or proctoring. As the Student / Coursework Owner, I should have Homework Buddee never bypass CAPTCHA, MFA, authentication, access controls, anti-bot protections, or proctoring, and pause for me when human verification is required. Provenance: explicit. Trigger: a human-verification event. Observable result: the agent pauses and hands control to the student. Failure/recovery: the pause is stated with the reason. Continuation: the workflow resumes after the student completes verification. Access: login.

FR-27 — Support Sophia Learning as an important use case. As the Student / Coursework Owner, I should have Sophia Learning supported: determine COURSE → UNIT → SECTION → TUTORIAL/CHALLENGE, read the relevant Sophia tutorial before helping with questions based on it, maintain Sophia terminology and conceptual framing, identify major concepts, Terms to Know, summaries, and relevant lesson content, and maintain enough context to avoid rereading everything unnecessarily. Provenance: explicit. Trigger: a Sophia course task. Observable result: the tutorial is read and the context is retained. Failure/recovery: a failed read is reported and retried. Continuation: the next tutorial. Access: login.

FR-28 — Use Sophia material as the primary source when assistance is permitted. As the Student / Coursework Owner, I should have Sophia material used as the primary source when assistance is permitted. Provenance: explicit. Trigger: a Sophia question. Observable result: the answer uses Sophia material. Failure/recovery: if the material is unavailable, the agent says so. Continuation: the answer proceeds with the limitation stated. Access: login.

FR-29 — Switch to tutoring, explanation, review, practice, and study assistance when outside AI assistance is prohibited. As the Student / Coursework Owner, I should have Homework Buddee switch to tutoring, explanation, review, practice, and study assistance when outside AI assistance is prohibited for an assessment, and never bypass proctoring or assessment security. Provenance: explicit. Trigger: an assessment where outside AI assistance is prohibited. Observable result: the mode switches and the assessment is not assisted. Failure/recovery: if the prohibition is unclear, the agent asks. Continuation: the tutoring/review/practice mode continues. Access: login.

FR-30 — Follow the question workflow for permitted coursework/practice questions. As the Student / Coursework Owner, I should have the question workflow followed for permitted coursework/practice questions: 01 read the complete question; 02 identify exactly what it asks; 03 inspect all choices; 04 locate the relevant course material; 05 compare choices against that material; 06 determine the supported answer; 07 verify the intended selection before interacting; 08 verify the resulting state afterward; accuracy is more important than speed. Provenance: explicit. Trigger: a permitted coursework/practice question. Observable result: the supported answer is determined and the resulting state is verified. Failure/recovery: a failed verification re-inspects the question. Continuation: the next question. Access: login.

FR-31 — Create and read supported document formats. As the Student / Coursework Owner, I should have DOCX, PDF, PPTX, XLSX/CSV, research notes, study guides, outlines, and bibliographies created and read where supported. Provenance: explicit. Trigger: a document is needed or supplied. Observable result: the document is created or read. Failure/recovery: an unsupported format is reported with an alternative. Continuation: the next document. Access: login.

FR-32 — Follow exact assignment formatting. As the Student / Coursework Owner, I should have exact assignment formatting followed: font, size, margins, spacing, headers, page numbers, indentation, headings, citations, filename, and file type. Provenance: explicit. Trigger: a document is created. Observable result: the formatting rules are applied. Failure/recovery: a missing rule is requested from the student. Continuation: the document is finalized. Access: login.

FR-33 — Aim for a submission-ready deliverable unless a draft is requested. As the Student / Coursework Owner, I should receive a submission-ready deliverable unless I request a draft. Provenance: explicit. Trigger: a document is created. Observable result: the deliverable is submission-ready. Failure/recovery: if submission-readiness cannot be reached, the gap is stated. Continuation: the student decides. Access: login.

FR-34 — Self-improvement on correction. As the Student / Coursework Owner, when I correct Homework Buddee, I should have the cause determined as factual, course-context, research, citation, writing-style, formatting, rubric, browser-navigation, tool-use, or instruction-following, and if 8080.ai supports editable skills/workflows/memory, the appropriate component improved so the error is less likely to recur. Provenance: explicit. Trigger: a student correction. Observable result: the cause is classified and the component is improved. Failure/recovery: if the component is not editable, the student is told and the closest editable component is improved. Continuation: the next task applies the improvement. Access: login.

FR-35 — Find or create 8080.ai equivalents for the listed tools. As the Student / Coursework Owner, I should have 8080.ai equivalents found or created for Academic Research, Citation Management, Student/Coursework Assistant, Browser Agent, College Exam/Study Preparation, Document/presentation creation, Persistent memory, Web research, File/PDF/document tools, Knowledge bases, API/tool integrations, and persistent browser sessions if available. Provenance: explicit. Trigger: the build reaches the tool-mapping step. Observable result: each equivalent is found or created. Failure/recovery: an unavailable equivalent is reported. Continuation: the next equivalent. Access: login.

FR-36 — Create the reusable homework-buddee-academic-workflow skill. As the Student / Coursework Owner, I should have a reusable custom skill/workflow named homework-buddee-academic-workflow that enforces the academic workflow, course-material priority, research standards, citation verification, writing-style preservation, instructor-feedback learning, rubric verification, browser reliability, progress tracking, and final quality control. Provenance: explicit. Trigger: the build reaches the skill step. Observable result: the skill exists and enforces the listed rules. Failure/recovery: if the skill cannot be created, the student is told and the closest editable component is used. Continuation: the skill is applied to the next task. Access: login.

FR-37 — Build in the specified order. As the Student / Coursework Owner, I should have the build proceed in this order: (1) persistent Homework Buddee agent/profile, (2) core identity/system instructions, (3) persistent memory, (4) academic workflow, (5) research and citations, (6) files/document capabilities, (7) browser/computer use, (8) Sophia workflow, (9) writing-style learning, (10) instructor-feedback learning, (11) rubric/final quality control, (12) confirmation rules for consequential actions, (13) end-to-end testing. Provenance: explicit. Trigger: the build starts. Observable result: each step completes in order. Failure/recovery: a failed step halts the build with the reason shown. Continuation: the build resumes from the failed step. Access: login.

FR-38 — Test, do not assume. As the Student / Coursework Owner, I should have these tests performed: a harmless browser navigation/read test; a harmless-preference store-and-retrieve memory demonstration if supported; a test-document read; a test-document creation; and a real-source retrieval and citation. Provenance: explicit. Trigger: the build reaches testing. Observable result: each test runs and its result is shown. Failure/recovery: a failed test is reported and re-run. Continuation: the next test. Access: login.

FR-39 — Tell the student where to enter credentials securely. As the Student / Coursework Owner, if credentials are required, I should be told where to enter them securely rather than being asked to paste secrets into chat. Provenance: explicit. Trigger: a credential is required. Observable result: the secure entry location is named. Failure/recovery: if no secure location exists, the agent says so. Continuation: the workflow resumes after entry. Access: login.

FR-40 — Final target: resume a course from a spoken objective. As the Student / Coursework Owner, I should be able to open Homework Buddee and say "Continue my U.S. Government course. Read the current lesson and help me work through it," and have Homework Buddee determine context, access appropriate permitted materials, read the lesson, maintain course context, research when needed, assist with coursework, create required documents, apply instructor feedback, verify its work, and maintain progress without rebuilding the setup each session. Provenance: explicit. Trigger: the student speaks the objective. Observable result: the agent resumes the course and works through the lesson. Failure/recovery: a failed step is reported and the workflow resumes from the last verified stage. Continuation: the next lesson. Access: login.

FR-41 — Establish application identity through Login. As the Student / Coursework Owner, I should establish application identity through Login before accessing protected agent configuration, memory, coursework, documents, and testing. Provenance: required_inference. Trigger: the student opens a protected surface. Observable result: the student is routed to Login and, on success, to the requested surface. Failure/recovery: a failed verification shows an inline error and grants no partial access. Continuation: the student retries or returns to Landing. Access: none (Login itself is anonymously reachable).

FR-42 — Persist the agent profile and the reusable skill before recurring coursework resumes. As the Student / Coursework Owner, I should have the Homework Buddee agent profile and the homework-buddee-academic-workflow skill persisted before recurring coursework can resume across sessions. Provenance: required_inference. Trigger: the student returns in a new session. Observable result: the profile and skill are present and applied. Failure/recovery: a missing profile or skill is reported and recreated. Continuation: the coursework resumes. Access: login.

FR-43 — Enter external educational-site credentials through secure mechanisms. As the Student / Coursework Owner, I should enter required external educational-site credentials through secure provider or browser mechanisms, and secrets must not be pasted into chat or stored in memory. Provenance: required_inference. Trigger: an external site requires credentials. Observable result: the credential is entered securely and the session proceeds. Failure/recovery: if the secure mechanism is unavailable, the agent says so. Continuation: the workflow resumes. Access: login.

FR-44 — Participate in human-verification events. As the Student / Coursework Owner, I should participate when human verification, MFA, CAPTCHA, proctoring, or another access-control event occurs. Provenance: required_inference. Trigger: a human-verification event. Observable result: the agent pauses and the student completes verification. Failure/recovery: if the student cannot complete it, the workflow halts with the reason shown. Continuation: the workflow resumes. Access: login.

FR-45 — Confirm consequential actions before execution. As the Student / Coursework Owner, I should explicitly confirm consequential actions before they execute. Provenance: required_inference. Trigger: a consequential action is reached. Observable result: the action waits for approval and proceeds only on approval. Failure/recovery: a declined action is cancelled. Continuation: the workflow resumes. Access: login.

4. User Personas

Student / Coursework Owner

Product context. The student owns the 8080.ai account and the coursework. They work at a browser all day across essay-heavy online courses, including Sophia Learning and U.S. Government. They are the sole human actor in this product.

Primary goal. To open Homework Buddee, state an objective in plain language, and have the agent resume the course, read the lesson, research, draft, format, verify, and report — without rebuilding the setup each session.

Distinct accepted responsibilities. The student gives objectives; supplies course materials, writing samples, instructor feedback, and graded work; reviews the agent's work; provides corrections that become learning information; and authorizes consequential actions (final submission, sending communications, purchases, deleting important information, and changing important account settings). The student also completes human-verification events (CAPTCHA, MFA, authentication, access controls, proctoring) and enters external credentials through secure mechanisms.

Relevant inputs or decisions. The objective statement; course materials; rubrics; writing samples; corrections and graded work; citation-style requirements; formatting rules; the decision to approve or decline a consequential action; the decision to switch to tutoring/review/practice mode when outside AI assistance is prohibited.

Interactions with other accepted participants. The student interacts with the Homework Buddee Academic Agent as the worker and with external educational platforms (Sophia Learning and other course sites) as the source of course material. The student is the only human; the agent is the only other accepted persona.

Observable success. The student opens Homework Buddee, speaks the objective, and sees the agent determine context, read the lesson, maintain course context, research when needed, assist with coursework, create required documents, apply instructor feedback, verify its work, and maintain progress — with a proof strip showing exactly what was read, retrieved, and verified.

What makes this role different. The student is the authorizer and the voice. The agent does the reading, research, drafting, and verification; the student owns the judgment calls, the corrections, and the consequential approvals. The student's work is not "using the app" — it is supplying the raw material (materials, samples, feedback) and making the decisions the agent is not permitted to make alone.

Homework Buddee Academic Agent

Product context. Homework Buddee is the persistent autonomous academic assistant being built inside 8080.ai. It is a configured agent, not a generic chatbot, and it lives in two worlds at once: the course page it reads and the document it writes.

Primary goal. To behave like an academic agent: identify course/unit/section/lesson/assignment context, read course material and rubrics, build requirement checklists, complete and verify work, manage citations and documents, navigate educational websites via browser automation, maintain global/course/assignment/feedback memory, learn the student's writing style, apply instructor feedback, and perform final quality control before reporting completion.

Distinct accepted responsibilities. The agent performs the 12-step academic workflow; enforces course-material priority; applies research standards; supports and verifies citations; preserves the student's writing style; learns from instructor feedback; reads and creates documents; operates the browser under the ten reliability rules; maintains Sophia context; runs the question workflow; performs self-improvement on correction; maintains the homework-buddee-academic-workflow skill; and runs capability tests, marking VERIFIED only after successful testing.

Relevant inputs or decisions. The student's objective; course materials; rubrics; instructor comments; uploaded files; formatting rules; citation requirements; prior work; writing samples; corrections; the assistance-permission state for an assessment; the decision to pause for human verification; the decision to ask before a consequential action.

Interactions with other accepted participants. The agent interacts with the Student / Coursework Owner as its principal and authorizer, and with external educational platforms and research sources as providers of material. It never bypasses CAPTCHA, MFA, authentication, access controls, anti-bot protections, or proctoring.

Observable success. The student can open Homework Buddee each session and continue coursework without rebuilding the setup. The agent's work is auditable through the proof strip, and its completion report is concise and accurate.

What makes this role different. The agent is the worker, not the authorizer. It has high autonomy for harmless and reversible work but must ask before consequential or difficult-to-reverse actions. It is the only actor that reads course material, researches, drafts, verifies, and reports — and the only actor that must never fabricate a source or report success without verification.

5. Core User Flows

Flow 1 — First-time build and configuration (Student / Coursework Owner)

1. The student opens Landing anonymously and reads what Homework Buddee is, who it is for, and its boundaries.
2. The student proceeds to Login and verifies identity. On success, the student lands on Dashboard.
3. The student opens Capability Map and runs the environment inspection. The agent produces the REQUIREMENT -> 8080.AI FEATURE -> NATIVE/EXTERNAL -> CONFIGURATION NEEDED mapping from the actual 8080.ai account.
4. The student opens Agent Profile and saves the persistent Homework Buddee identity and core system instructions, including the autonomy policy and boundary statements. The profile persists across logout/restart.
5. The student opens Memory and confirms the four scopes (Global / Course / Assignment / Feedback) and the secret-exclusion rule.
6. The student opens Workflow and confirms the 12-step sequence is in force.
7. The student opens Research, Documents, Browser, Sophia, Writing Style, Feedback, and Quality Control in turn, confirming each is configured.
8. The student opens Confirmations and confirms the approval gates for final submission, sending communications, purchases, deleting important information, and changing important account settings.
9. The student opens Skills and creates the homework-buddee-academic-workflow skill.
10. The student opens Testing and runs the required tests: a harmless browser navigation/read test; a harmless-preference store-and-retrieve memory demonstration if supported; a test-document read; a test-document creation; and a real-source retrieval and citation.
11. Each capability is marked VERIFIED only after its test succeeds. A failed test is reported with the reason and re-run.
12. Failure/recovery: if the environment inspection fails, the student retries it; previously confirmed mappings are preserved. If a capability is unavailable, the student is told and the closest persistent alternative is used.
13. Continuation: the student proceeds to daily coursework.

Flow 2 — Resume a course from a spoken objective (Student / Coursework Owner)

1. The student opens Dashboard and says: "Continue my U.S. Government course. Read the current lesson and help me work through it."
2. The agent determines context: course, unit/module, section, lesson/tutorial, and assignment (workflow stage 01).
3. The agent reads the relevant course material (stage 02) and the complete instructions and rubric (stage 03).
4. The agent inspects required readings, examples, instructor comments, uploaded files, formatting rules, citation requirements, and relevant prior work (stage 04).
5. The agent builds an internal checklist of every requirement (stage 05), rendered as the mono rubric checklist in the split-dialog task view.
6. The agent completes the work (stage 06), drafting in the right column while the rubric criteria remain visible in the left column at the same scroll position.
7. The agent verifies facts and citations (stage 07), retrieving real sources through Research and binding each claim to a verified source.
8. The agent compares the result against every rubric criterion (stage 08), wiping each verified line with a 1px accent underline in order.
9. The agent checks every question/sub-question (stage 09).
10. The agent checks formatting and required deliverables (stage 10) through Documents.
11. The agent performs final quality control (stage 11) through Quality Control.
12. The agent gives a concise completion report (stage 12), with a proof strip showing the URLs read, page state changes, sources retrieved, and timestamps.
13. Failure/recovery: if a stage fails, the workflow halts at that stage with the reason shown and resumes from the last verified stage without redoing verified work.
14. Continuation: the student reviews the report and either accepts the work or provides a correction.

Flow 3 — Sophia Learning tutorial and question workflow (Student / Coursework Owner)

1. The student opens Sophia and navigates the COURSE → UNIT → SECTION → TUTORIAL/CHALLENGE tree in the left ink rail.
2. The agent reads the relevant Sophia tutorial before helping with questions based on it, maintaining Sophia terminology and conceptual framing.
3. The agent identifies major concepts, Terms to Know, summaries, and relevant lesson content, and retains enough context to avoid rereading everything unnecessarily.
4. For a permitted coursework/practice question, the agent follows the question workflow: reads the complete question; identifies exactly what it asks; inspects all choices; locates the relevant course material; compares choices against that material; determines the supported answer; verifies the intended selection before interacting; and verifies the resulting state afterward. Accuracy is more important than speed.
5. Failure/recovery: if the agent encounters CAPTCHA, MFA, authentication, access control, anti-bot protection, or proctoring, it pauses and hands control to the student. The student completes the verification and the workflow resumes.
6. Continuation: if outside AI assistance is prohibited for an assessment, the mode switches to tutoring, explanation, review, practice, and study assistance, and the assessment is not assisted.

Flow 4 — Research and citation (Student / Coursework Owner)

1. The student opens Research for the current assignment.
2. The agent retrieves sources, prioritizing primary sources, government sources, universities, peer-reviewed scholarship, scholarly publications, official institutions, established research organizations, and high-quality journalism where appropriate.
3. The agent verifies important claims against the retrieved sources.
4. The agent determines the required citation style from the assignment (MLA, APA, Chicago, or instructor-specific).
5. The agent ensures in-text citations and References/Works Cited correspond.
6. The agent verifies that each cited source actually supports the associated claim.
7. Failure/recovery: if a source cannot be verified, it is excluded and the student is told; no citation is emitted for an unverified source. The agent never fabricates a source, author, quotation, URL, DOI number, page number, publication date, or citation.
8. Continuation: the verified citations are attached to the current assignment and appear in the deliverable.

Flow 5 — Document creation and reading (Student / Coursework Owner)

1. The student opens Documents for the current assignment.
2. The agent reads any supplied coursework files (DOCX, PDF, PPTX, XLSX/CSV, research notes, study guides, outlines, bibliographies) where supported.
3. The agent applies the exact assignment formatting: font, size, margins, spacing, headers, page numbers, indentation, headings, citations, filename, and file type.
4. The agent creates the deliverable. Unless the student requested a draft, the deliverable is submission-ready.
5. Failure/recovery: if a format is unsupported, the student is told and offered a supported alternative. If a formatting rule is missing, the agent asks the student.
6. Continuation: the deliverable is attached to the assignment and appears in the completion report.

Flow 6 — Browser navigation and reading (Student / Coursework Owner)

1. The student opens Browser and requests a permitted educational navigation or read.
2. The agent inspects the page before acting, prefers semantic controls/DOM data (accessible roles, labels, button names, link text, visible text, stable attributes), avoids fragile coordinate clicking when semantic controls exist, waits for dynamic content to become visible/actionable, scrolls targets into view, and detects overlays, dialogs, cookie notices, and pop-ups.
3. The agent verifies the intended selection/input before proceeding and verifies the expected page/state change after the action.
4. Failure/recovery: if an action fails, the agent inspects the page again instead of blindly repeating clicks. If CAPTCHA, MFA, authentication, access control, anti-bot protection, or proctoring is encountered, the agent pauses and hands control to the student.
5. The agent never reports success without verification. The proof strip shows the URL, page state, and timestamp.
6. Continuation: the next permitted navigation or read.

Flow 7 — Writing-style learning (Student / Coursework Owner)

1. The student opens Writing Style and adds a writing sample or a correction.
2. The agent analyzes vocabulary, sentence structure, paragraph length, tone, organization, transitions, formality, argument structure, use of evidence, and conclusions.
3. The agent derives a style profile and previews it applied to a passage.
4. The agent improves clarity, grammar, organization, evidence, and compliance without converting the work into generic AI prose.
5. Failure/recovery: if derivation fails, the reason is shown and the sample is retained for retry.
6. Continuation: the profile is applied to the next draft.

Flow 8 — Instructor-feedback learning (Student / Coursework Owner)

1. The student opens Feedback and provides corrections or graded work.
2. The agent determines what the instructor wanted changed; corrects the current issue; identifies the underlying rule/preference; stores it in Course Memory when appropriate; and applies it to future work for that course.
3. The agent does not repeatedly make a mistake already corrected.
4. Failure/recovery: if the underlying rule cannot be identified, the agent asks the student.
5. Continuation: the rule applies to the next assignment in that course.

Flow 9 — Self-improvement on correction (Student / Coursework Owner)

1. The student corrects Homework Buddee.
2. The agent determines whether the cause was factual, course-context, research, citation, writing-style, formatting, rubric, browser-navigation, tool-use, or instruction-following.
3. If 8080.ai supports editable skills/workflows/memory, the agent improves the appropriate component so the error is less likely to recur.
4. Failure/recovery: if the component is not editable, the student is told and the closest editable component is improved.
5. Continuation: the next task applies the improvement.

Flow 10 — Consequential-action confirmation (Student / Coursework Owner)

1. The agent reaches a consequential or difficult-to-reverse action: final submission, sending communications, purchases, deleting important information, or changing important account settings.
2. The agent opens Confirmations and presents the action's exact scope with its proof strip.
3. The student approves or declines.
4. Failure/recovery: a declined action is cancelled and the workflow continues without it. If the action fails after approval, the reason is shown inline.
5. Continuation: the workflow resumes.

Flow 11 — Capability testing (Student / Coursework Owner)

1. The student opens Testing.
2. The agent runs the required tests: a harmless browser navigation/read test; a harmless-preference store-and-retrieve memory demonstration if supported; a test-document read; a test-document creation; and a real-source retrieval and citation.
3. Each capability is marked VERIFIED only after its test succeeds.
4. Failure/recovery: a failed test is reported with the reason and re-run; the capability remains unverified until a successful run.
5. Continuation: the next test, then daily coursework.

Flow 12 — Credential entry for external educational sites (Student / Coursework Owner)

1. The agent determines that an external educational site requires credentials.
2. The agent tells the student where to enter them securely rather than asking the student to paste secrets into chat.
3. The student enters the credentials through the secure provider or browser mechanism.
4. Failure/recovery: if no secure mechanism is available, the agent says so and the workflow halts at that point.
5. Continuation: the workflow resumes after entry. Secrets are never stored in memory.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Adham Dannaway; the headline concept is split-brain craft: the agent that reads the lesson and writes the paper.

Colour tokens (light mode).

Accent text is never used below 14px.

Typography.

• Headings: Fraunces, soft "wonky" optical size, low contrast, 64–96px, weight 500–600, tracking -0.02em, sentence case, ragged right, never centred.
• Technical/machine output: JetBrains Mono for rubric criteria, citation strings, file names, memory keys, and verification logs — 13–14px, uppercase for labels with 0.08em tracking, sentence case for content.
• Body: Archivo at weight 400–500 with a slightly loose 1.6 line-height.
• Scale: 1.333 modular — 96 / 72 / 48 / 32 / 24 / 17 / 14 / 12. Display 96 and 72 for the hero and section openers; 48 for split-half titles; 32 for course/assignment headers; 24 for card titles; 17 for body; 14 for secondary; 12 for mono micro-labels.

Shape language. Two shapes in deliberate tension. The paper half uses soft 4px radii and hairline 1px borders in #E3DDD0 — almost square, editorial, like a printed worksheet. The code half uses sharp 0px corners with a 1px #2A2E36 border and a 3px left rule in accent when a line is "active". Pills are reserved only for the agent's live status chip. No blob shapes, no 24px "friendly" radii, no offset drop shadows — elevation is a 2px bottom rule and a subtle 1px border, never a blur.

Spacing rhythm. A 12-column grid with a 720px reading measure for prose and a wider 960px for checklist and rubric tables. The left rail is 240px. Section transitions are a hard horizontal rule, not a card boundary.

Imagery style. No stock photography, no illustration. The visual vocabulary is the interface itself plus two authored asset types: (1) a small set of 1.5px-stroke line pictograms in ink navy for the nine tools (browser, document, citation, memory, research, feedback, rubric, file, skill) drawn on the same 24px grid so they read as a family; (2) "proof strips" — a horizontal row of mono text showing the actual verification trail (URL read, page state, source retrieved, timestamp) rendered as a screenshot-like band under any completed task. Where a course page must be shown, it is shown as a cropped, desaturated monochrome browser frame with a single accent highlight on the element that was read.

Forbidden. The generic indigo/blue-on-white SaaS template; Inter, Roboto, Poppins, system-ui, or any UI sans that reads as a template default; a grid of identical rounded cards with hover-lift shadows; friendly-education aesthetics (rounded blob shapes, waving characters, pastel primaries, sticker badges); purple/indigo or blue-on-white accent as the primary brand colour; soft 24px radii, blur-heavy glassmorphism panels, or ambient gradient washes; decorative motion; progress expressed as a percentage ring or bar.

7. Signature Design Concept

The Split Desk. The public entry is a full-viewport split down the middle — not a centred SaaS hero. The left half is warm paper (#F4F1EA): a 96px Fraunces headline stacked in three lines reading "READ THE LESSON. / WRITE THE PAPER. / SHOW YOUR WORK.", ragged left, with a single accent-underlined line beneath it, and below that a live mono checklist of the current assignment's rubric criteria with two already ticked in accent. The right half is the dark ink column (#14161A) rendered as a terminal-like panel showing the agent's actual activity log in JetBrains Mono — READING: Sophia → U.S. Government → Unit 3 → Tutorial 3.2, VERIFIED: source retrieved, 200 OK, MEMORY: course rule stored — with one accent cursor line at the bottom.

The split is offset, not 50/50: 58% paper, 42% ink, so the composition is asymmetric and the eye lands on the headline first, then travels right into the proof. No button in the centre, no gradient, no blob — the only accent-coloured element above the fold is the two ticked rubric lines and the cursor.

The concept recomposes accepted content only: the headline states the product's two halves; the rubric checklist is the workflow's requirement checklist; the activity log is the proof strip. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: restrained Hero Dimensionality: layered_2d

Landing Hero Motion Brief.

• Focal subject: the split desk — the paper half with the three-line Fraunces headline and the live rubric checklist, and the ink half with the agent's activity log.
• Input → transformation → outcome thesis: as the student reads the headline, the two ticked rubric lines wipe left-to-right in 180ms with a 1px accent underline, and the ink half's activity log advances one line at a time in JetBrains Mono, ending on a single accent cursor line. The transformation is the visible proof that verification happened; the outcome is the student's understanding that the agent reads and writes.
• Motion vocabulary: exactly three motions exist. (1) The left-rail agent chip pulses a 1.2s accent dot while working and settles to a static dot on completion. (2) Rubric checklist lines wipe left-to-right in 180ms with a 1px accent underline as they are verified, one at a time, in order. (3) The split halves cross-fade their content in 240ms when switching between "course material" and "my draft". No parallax, no hover-lift, no type animation.
• Composed first frame: the paper half at 58% with the headline fully set and the rubric checklist showing two ticked lines; the ink half at 42% with the activity log showing three lines and the accent cursor at the bottom.
• Reduced-motion state: all three motions are suppressed; the rubric checklist shows its ticked lines statically with the accent underline already drawn, the activity log shows its lines without advancing, and the agent chip shows a static dot. The composition is unchanged.

9. Non-Functional Requirements

• NFR-01 — Persistence across sessions. Settings, agent profile, memory, and the reusable skill survive logout/restart. Provenance: explicit. Rationale: the student must not rebuild the setup each session.
• NFR-02 — Native-first. Prefer native 8080.ai features over external services. Provenance: explicit. Rationale: reliability, low cost, and minimal command-line administration.
• NFR-03 — Low cost. Prefer low-cost/free models when adequate. Provenance: explicit. Rationale: the student's stated implementation priority.
• NFR-04 — Browser-based daily operation. The daily workflow runs in the browser. Provenance: explicit. Rationale: the student works at a browser all day.
• NFR-05 — Few external services. Minimize external service dependencies. Provenance: explicit. Rationale: reliability and easy recovery.
• NFR-06 — Easy recovery. Failures are recoverable without rebuilding the setup. Provenance: explicit. Rationale: the student's stated implementation priority.
• NFR-07 — Minimal command-line administration. The student should not need command-line work for daily operation. Provenance: explicit. Rationale: the student's stated implementation priority.
• NFR-08 — Secret exclusion. Passwords, private keys, API keys, tokens, and unnecessary secrets are never stored in memory. Provenance: explicit. Rationale: the student's stated hard constraint.
• NFR-09 — No fabrication. Sources, authors, quotations, URLs, DOI numbers, page numbers, publication dates, and citations are never fabricated. Provenance: explicit. Rationale: academic integrity and the student's stated hard constraint.
• NFR-10 — No bypass. CAPTCHA, MFA, authentication, access controls, anti-bot protections, and proctoring are never bypassed. Provenance: explicit. Rationale: the student's stated hard constraint and the platforms' security.
• NFR-11 — No unverified success. Success is never reported without verification. Provenance: explicit. Rationale: the student's stated hard constraint.
• NFR-12 — VERIFIED only after testing. Capabilities are marked VERIFIED only after successful testing. Provenance: explicit. Rationale: the student's stated hard constraint.
• NFR-13 — Accessible contrast. Body text on paper is #14161A at 16–17px for AA contrast; accent text is never used below 14px. Provenance: creative direction. Rationale: readability of long rubric text.
• NFR-14 — Reduced-motion support. The three motions are suppressed under reduced-motion preferences without changing the composition. Provenance: creative direction. Rationale: accessibility.

10. Tech Stack

Source choices are preserved first.

• Agent runtime and surfaces: 8080.ai native agent/profile, persistent memory, browser/computer-use system, document tooling, research tooling, and knowledge-base/tool integrations. The first-party workspace surfaces (Landing, Login, Dashboard, Capability Map, Agent Profile, Memory, Workflow, Research, Documents, Browser, Sophia, Writing Style, Feedback, Quality Control, Confirmations, Skills, Testing) are delivered inside the 8080.ai environment.
• Frontend: React, browser-based, using the creative direction's tokens (Fraunces, JetBrains Mono, Archivo; the palette in section 6).
• Backend: Python / FastAPI for any first-party service logic the 8080.ai environment requires.
• Storage: the 8080.ai persistent storage substrate for the four memory scopes, agent profile, skill definition, coursework state, and generated documents.
• Deployment: Docker / docker-compose where the 8080.ai environment requires containerized services. Kubernetes only if deployment requires it.
• External services: minimized per NFR-05. External educational platforms (Sophia Learning and other course sites) are accessed through the browser/computer-use system, not through bespoke integrations.

11. Assumptions and Constraints

Assumptions.

• A-01 — The student has an active 8080.ai account with access to the native agent/profile, memory, browser/computer-use, document, and research capabilities. [Default — not specified by user]
• A-02 — The 8080.ai environment exposes a persistent storage substrate sufficient for the four memory scopes. If it does not, the closest persistent alternative is used and the student is told. [Default — not specified by user]
• A-03 — The student's courses are reachable through the browser/computer-use system and do not require bypassing CAPTCHA, MFA, authentication, access controls, anti-bot protections, or proctoring. Provenance: explicit.
• A-04 — The student will complete human-verification events when the agent pauses. Provenance: required_inference.
• A-05 — The student will enter external credentials through secure provider or browser mechanisms. Provenance: required_inference.

Constraints.

• C-01 — Do not merely explain how to build Homework Buddee; actually build it in the student's 8080.ai account. Provenance: explicit.
• C-02 — Do not stop after the capability map or after recommendations. Provenance: explicit.
• C-03 — Ask before consequential or difficult-to-reverse actions: final submission, sending communications, purchases, deleting important information, and changing important account settings. Provenance: explicit.
• C-04 — Do not silently replace course content with general AI knowledge; clearly distinguish outside information that differs from supplied course materials. Provenance: explicit.
• C-05 — Never fabricate sources, authors, quotations, URLs, DOI numbers, page numbers, publication dates, or citations. Provenance: explicit.
• C-06 — Do not store passwords, private keys, API keys, tokens, or unnecessary secrets. Provenance: explicit.
• C-07 — Do not bypass CAPTCHA, MFA, authentication, access controls, anti-bot protections, or proctoring; pause for the student when human verification is required. Provenance: explicit.
• C-08 — If outside AI assistance is prohibited for an assessment, switch to tutoring, explanation, review, practice, and study assistance; never bypass proctoring or assessment security. Provenance: explicit.
• C-09 — Do not report success without verification. Provenance: explicit.
• C-10 — If credentials are required, tell the student where to enter them securely rather than asking the student to paste secrets into chat. Provenance: explicit.
• C-11 — Mark capabilities VERIFIED only after successful testing; test, do not assume. Provenance: explicit.
• C-12 — Prefer native 8080.ai features, persistent solutions, reliable automation, browser-based daily operation, low-cost/free models when adequate, reusable workflows, minimal command-line administration, few external services, settings that survive logout/restart, and easy recovery. Provenance: explicit.
• C-13 — The generic indigo/blue-on-white SaaS template is forbidden for this project. Provenance: creative direction.

12. Glossary

• Homework Buddee — the persistent autonomous academic assistant built inside the student's 8080.ai account.
• 8080.ai — the provider platform hosting the agent runtime, memory, browser/computer-use system, document tooling, and research tooling.
• Academic workflow — the 12-step sequence from context identification through completion reporting.
• Course-material priority — the rule that supplied course materials are the primary authority for questions about that course.
• Global User Memory — durable writing, formatting, and workflow preferences.
• Course Memory — course name, terminology, instructor rules, citation style, formatting, feedback, and progress.
• Assignment Memory — current assignment, relevant lesson, rubric checklist, sources, draft state, completed and remaining requirements.
• Feedback Memory — student corrections, instructor corrections, recurring mistakes, and successful approaches.
• Rubric checklist — the mono, left-aligned list of every requirement pulled from the rubric, with each criterion wiped in a 1px accent underline the moment it is verified.
• Proof strip — the horizontal mono band beneath a completed task showing the exact URLs read, page state changes, sources retrieved, and timestamps.
• Split-dialog task view — the two-column task view with rubric criteria in mono on the left and the draft on the right at the same scroll position.
• homework-buddee-academic-workflow — the reusable custom skill enforcing the academic workflow, course-material priority, research standards, citation verification, writing-style preservation, instructor-feedback learning, rubric verification, browser reliability, progress tracking, and final quality control.
• VERIFIED — a capability status granted only after a successful test.
• Human verification — CAPTCHA, MFA, authentication, access-control, anti-bot, or proctoring events that require the student's participation.
• Assistance-permission state — whether outside AI assistance is permitted for a given assessment; when prohibited, the agent switches to tutoring, explanation, review, practice, and study assistance.
• Sophia Learning — an important external educational platform whose COURSE → UNIT → SECTION → TUTORIAL/CHALLENGE structure the agent maintains.
• Consequential action — final submission, sending communications, purchases, deleting important information, or changing important account settings.