We'll provide the OctoSlides frontend repository for you to work on. Build your generation & agent layer against it.

The step-by-step slide-generation pipeline and the agent behaviour that plans and produces a deck — supporting two generation modes.

• Figure out the step-by-step slide-generation flow and the agent behaviour that drives it (outline → slides → content).
• Implement Mode 1 — Generation from template: build a deck from a chosen presentation template.
• Implement Mode 2 — HTML → PPTX: turn HTML content into a downloadable .pptx deck.
• Integrate with the provided frontend — real generation, no mock decks.

Amirjon & Chris work as one team on a shared branch — divide the pages between you, agree on shared mobile patterns, and integrate into one consistent mobile experience.

The Study Studio source lives in the Cockpit repo github.com/boardwalk-ai/Cockpit (packages/study_studio). The existing desktop layouts are your reference.

A purpose-built mobile layout for every Study Studio page — not a squeezed desktop — switched on isMobilePlatform, with the desktop layout left intact for wide screens.

• Go through every Study Studio page and design an independent mobile layout for each.
• Gate the mobile layout on isMobilePlatform — the desktop layout stays for wide screens.
• Keep behaviour identical; only the layout & UX adapt to the phone form factor.
• Reusable mobile patterns · touch-friendly targets · no horizontal overflow.
• Cooperate on a shared branch; submit via fork PR on the Cockpit repo.

Sean, Amirjon & Chris build this as one team on a shared branch. Agree on the architecture up front, split the surface (frontend / Go APIs / Python AI layer) between you, and integrate into a single working module — cooperate closely and keep each other unblocked.

The official Writing Chamber code lives in github.com/boardwalk-ai/OctopilotWeb. Study how it works, then rewrite it in the Cockpit stack — same behaviour, our architecture.

The full Writing Chamber module — the Flutter UI (editor, controls, panels), the Go APIs it depends on, and the Python AI layer — matching the official product's features and flow.

• Study the Writing Chamber in OctopilotWeb; map its screens, features and data flow.
• Rebuild the Flutter frontend — layout, editor, controls, and every UI state.
• Build the Go backend — the APIs the chamber needs (save / load, sessions, credits).
• Build the Python AI layer — generation + SSE streaming into the UI.
• Agree a clean contract between the three layers; wire real loading / empty / error / result — no mock data.
• Work on a shared branch; submit via fork-based pull request on the Cockpit repo.

The official HumanizerHub code lives in github.com/boardwalk-ai/OctopilotWeb. Study it, then rewrite it in the Cockpit stack — same behaviour, our architecture.

The full HumanizerHub module — the Flutter UI (input, humanize controls, output), the Go APIs, and the Python humanize / AI layer — matching the official product.

• Study HumanizerHub in OctopilotWeb; map its features and flow.
• Rebuild the Flutter frontend — input, humanize options/controls, output, and every UI state.
• Build the Go backend — the APIs it needs (sessions, save / load, credits).
• Build the Python layer — the humanize / AI processing (streaming where it applies).
• Wire real states end to end — no mock data; submit via fork-based PR on the Cockpit repo.

Your own two builds: the GhostWriter UI from Assignment 02 and the GhostWriter agent backend from Assignment 03. This week they meet.

The full wiring — the Flutter UI talking to the Go APIs over HTTP and to the Python AI layer over SSE streaming. Every mock/stub state replaced by live data from your backend.

• Wire the UI to the Go APIs — saving, folder loading, user-credits.
• Stream AI output into the UI over SSE — token-by-token, live.
• Replace every mock state with real loading / empty / error / result from the backend.
• Show credits + session straight from the backend; carry the semantic chat memory across turns.
• Wire the GhostWriter editor to the shared citation formatters (task 03) — insert citations, build the reference list, switch styles.
• Fail gracefully — network errors, dropped streams, retries.

Amirjon & Chris — one Mode, one editor. Divide the editor between you and integrate into a single Flutter build. You also co-own the shared formatters in task 03 with Sean.

The full Guided-Generation editor — edit the generated document with rich text, sections, a formatting toolbar, inline citations and an auto-built references section, all consuming the shared citation formatters from task 03.

• Build the full editor — rich text, headings, lists, a formatting toolbar, editable sections.
• Inline citation insertion + an auto-built references / bibliography section.
• Consume the shared formatters (task 03) — a style switcher swaps the whole document's citations between styles live.
• Edits persist through your Assignment 03 backend (save / load).
• Responsive layout · reusable widgets · clean state handling.

Sean, Amirjon & Chris build this together as one shared module. It is the common dependency of both your editors — agree on a single contract, split the five styles, and integrate into one build both editors import.

The citation formatter implementations live in the now-public repo boardwalk-ai/OctopilotWeb. Study them and rewrite each formatter in Dart.

One shared Dart module exposing the five citation styles — APA, MLA, Chicago, IEEE, Harvard — behind a single interface both the GhostWriter editor and the Guided-Generation editor call, with identical results.

• One shared module, one common interface — both editors import it and get identical output.
• Rewrite all five in Dart: APA · MLA · Chicago · IEEE · Harvard — port from the OctopilotWeb reference.
• Each formatter: structured source fields (author, title, year, publisher, URL…) → correct in-text citation + full reference entry.
• Prove it works 100% in both editors — GhostWriter's editor and the Guided-Generation editor, live style switching in each.
• Handle edge cases — missing fields, multiple authors, no date, web vs print sources.
• Unit tests for every style against known-correct examples.

Take your crawl animation and drive it from a live token stream (SSE) instead of a mock timer, wrapped in a reusable streaming-text controller that exposes incremental text and typing/done state.

• Drive the crawl animation from real streamed tokens (SSE), not a mock timer.
• Build a reusable streaming-text controller — subscribe to a token stream, expose incremental text + typing / done state.
• Typing indicator / cursor while streaming; smooth append with no jank.
• Keep it viewport-fit — long streamed output still fits, no scrolling.
• A drop-in reusable widget any generation screen can use.

The tools reference for the main GhostWriter lives in the now-public repo boardwalk-ai/OctopilotWeb. Study it and rewrite the agent tools for this backend.

A two-language backend: GoLang for the APIs (saving, folder loading, user-credits loading, …) and Python for the AI/model calls — driven by rewritten agent tools and backed by a semantic memory for the chat session.

• Rewrite the agent tools — reference the tools used in the main GhostWriter (OctopilotWeb repo).
• Build GoLang APIs for the saving mechanism, folder loading, user-credits loading, etc.
• Use Python for the AI calls.
• Implement semantic memory for the chat session — persist and retrieve context across turns.
• You may use a self-hosted VectorDB for the agent's memory context.

Amirjon & Chris — since your Guided Generation frontend tasks are under one Mode, cooperate on this backend as one team: split the work and integrate it.

The agents reference for the main Guided-Generation lives in the now-public repo boardwalk-ai/OctopilotWeb. Study it and rewrite the agents for this backend.

A two-language backend: GoLang for the APIs (saving, folder loading, user-credits loading, …) and Python for the AI/model calls — driven by rewritten Guided-Generation agents.

• Cooperate — one Mode, one backend; divide and integrate the work between you.
• Rewrite the agents — reference the agents used in the main Guided-Generation (OctopilotWeb repo).
• Build GoLang APIs for the saving mechanism, folder loading, user-credits loading, etc.
• Use Python for the AI calls.

A reusable streaming reveal animation for AI output — the classic Star Wars opening-crawl feel, text emerging in perspective as it streams in — plus a layout pass over the Guided Generation pages you built last week so they fit the screen exactly.

• Design the Star Wars-style streaming animation for AI output — the perspective "crawl" reveal as tokens/content stream in.
• Make it smooth, performant and reusable — a widget any generation screen can drop in.
• Revisit your past pages (Generation → Humanizer) and adjust the layout to fit the viewport on every target screen size.
• No scrolling needed, no scrolling allowed — everything lives within the visible viewport at desktop and mobile widths.
• Responsive layout · reusable widgets · clean state handling.

Study and rebuild the page at octopilotai.app/ghostwriter. That live page is your single source of truth for layout, components and behaviour.

The full GhostWriter screen in Flutter — the prompt/input area, the writing controls & options, primary actions, and the generated-output area — matching the reference's structure and visual hierarchy.

• Match the reference's layout & visual hierarchy — spacing, typography, sections.
• Build every interactive control — inputs, toggles, dropdowns, primary/secondary buttons.
• Wire the UI states — empty, typing, loading, and result — against mock/stub data (no backend).
• Make it responsive across desktop and mobile widths.
• Compose it from reusable widgets with clean, tidy state handling.

Rebuild the Outline Generation step (the first page) of octopilotai.app/guided-generation. Follow the live page for structure and behaviour.

The Outline Generation screen in Flutter — the topic/prompt entry, generation controls, and the generated outline view with its editable sections and the "continue" step forward.

• Recreate the input & options that start an outline (topic, settings, generate action).
• Build the outline result view — sections/headings the user can review and edit.
• Wire UI states — empty, generating (loading), and generated — with mock/stub data.
• Include the step's navigation affordance (proceed to the next guided step).
• Responsive layout · reusable widgets · clean state handling.

Rebuild the Customization page of octopilotai.app/guided-generation — the step that includes the manual source search and the Octopilot search features.

The Customization screen in Flutter — the manual source search (query field, results, add/select), the Octopilot search feature, the list of chosen sources, and the customization controls.

• Build the manual source search — search field, result cards/list, add & remove sources.
• Build the Octopilot search feature UI alongside it (tabs/modes as in the reference).
• Show the selected-sources state and any customization options/controls.
• Wire UI states — empty, searching (loading), results, selected — with mock/stub data.
• Responsive layout · reusable widgets · clean state handling.

Rebuild the Generation page through the Humanizer umbrella page of octopilotai.app/guided-generation. The live pages define layout and behaviour.

Two connected Flutter screens — the Generation screen (content generation progress + the generated output), flowing into the Humanizer umbrella page (its humanize controls/options and output).

• Build the Generation screen — progress/generating state and the generated content view.
• Build the Humanizer umbrella page — its options/controls and the humanized output area.
• Wire the flow + states between them (generating → generated → humanize) with mock/stub data.
• Match the reference's layout and visual hierarchy on both screens.
• Responsive layout · reusable widgets · clean state handling.

The app has grown to many screens with almost no automated coverage. Your job is a fast, deterministic test suite that runs entirely against the in-memory repository and mock data — no backend, no network — so it's reliable in CI and quick to run locally.

Widget + golden tests for the six core screens, plus unit tests for the pure domain logic. Each screen test drives the UI through its real states and asserts what the user sees.

• Set up the test harness: ProviderScope overrides + shared mock studios.
• Widget tests for Home, Dashboard, Quiz Me, Flashcards, Teach Me, Mastery Report.
• For each screen, assert all four states — loading, empty, error, data.
• Golden (snapshot) tests for at least 3 visually rich screens.
• Unit tests for mastery calculation, weak-topic selection, and the DTO mappers.
• A README covering how to run the suite and add new tests.

Real users upload PDFs, DOCX and PPTX, but the ingestion pipeline currently only accepts .txt / .md. You'll build the missing extractor as a clean, isolated module the lead can drop straight in.

A standalone Python module (your own folder) that takes file bytes + filename + mime and returns clean, chunking-ready text. Wrap it with a thin FastAPI demo endpoint so it can be tested on its own.

• PDF via pypdf · DOCX via python-docx · PPTX via python-pptx.
• Detect format from mime/extension and dispatch to the right extractor.
• Clean output: collapse whitespace, drop repeated headers/footers/page numbers, keep paragraph breaks.
• Fail gracefully on unsupported / corrupt files (clear error, no crash).
• Match the contract exactly: extract_text(filename, mime, data) → str.
• Unit tests with small sample files + a POST /extract demo endpoint.

Short-answer and fill-in-the-blank questions are graded today by exact string match, so correct-but-worded-differently answers are marked wrong. You'll replace that with semantic scoring.

A standalone FastAPI microservice that scores a student's free-text answer against the correct answer using local embedding similarity — no external API key required.

• Endpoint: POST /grade { question, studentAnswer, correctAnswer } → { correct, score 0–1, feedback }.
• Use sentence-transformers embeddings + cosine similarity.
• Choose and justify a correctness threshold; handle empty / near-empty answers.
• Return short human feedback (e.g. "Close — you missed the mechanism").
• Tests over a labeled set — correct / partial / wrong — asserting expected verdicts.
• Stretch: optional LLM-judge fallback behind a flag.

After each deploy we need a quick, automated confidence check across the API surface. You'll build the smoke test that gates it — green means safe, red means stop.

A Python + httpx script that hits a set of endpoints, validates their responses, prints a clean pass/fail report, and exits non-zero on any failure so it can run in CI.

• Check public endpoints first (health / readiness), then a few authenticated ones.
• Assert status codes and the presence/shape of key response fields.
• Handle the streaming (SSE) response format where it applies.
• Clear console report with a summary line — X passed / Y failed.
• Read base URL + token from env vars (provided privately — never hard-coded).

To test uploads and content generation properly, the team needs believable study material across subjects and lengths. You'll build a generator that produces it on demand — the fixtures everyone else tests against.

A Python CLI script that outputs varied sample study documents in .txt and .md, structured like real notes — titles, sections, key terms and examples.

• Multiple subjects — Biology, History, Networking, Economics… (a template set each).
• Multiple sizes — from a short one-page note to a long multi-section chapter.
• Realistic structure: headings, lists, definitions, worked examples.
• CLI flags: --count, --subject, --size, --out.
• Short README with example commands.