You are writing an APPLICATION BLUEPRINT for this codebase. Read this whole instruction first, then read the entire codebase before you write anything. WHAT A BLUEPRINT IS A blueprint is not documentation, not a README, and not a summary of the code. It is a complete, self-contained specification from which a competent coding agent could rebuild this entire application from scratch, in any reasonable technology stack, WITHOUT ever seeing the current source. Treat the source code as disposable output. The blueprint is the durable artifact. Every decision that matters must live in the blueprint, because the code it came from will not be there. If a rule, a constraint, or a piece of reasoning exists only in the code and you do not write it down, it is lost, and the rebuild will get it wrong. Your task is to extract the ENGINEERING JUDGMENT, not to narrate the files. Capture the things that took real work to get right and that a one-line prompt like "build me an app that does X" would never recover: the exact workflows, the edge cases, the shape of the data and the reason it is shaped that way, the permission rules, the domain terminology, the validation, and the failure handling. The test of a good blueprint: two independent agents, each given only this document and no access to each other or to the original code, would build functionally equivalent applications. WHAT TO COVER Cover all of the following, in depth. Add sections if the application needs them. Do not drop a section because it seems obvious; state it. 1. PURPOSE AND SCOPE What the application does, who it is for, the problem it solves, and explicitly what is OUT of scope. State the core value in one paragraph a non-expert could follow, then the precise scope boundaries. 2. USERS AND ROLES Every role or user type. For each: what they can do, what they cannot do, and how the system decides which role a request has. Include anonymous or unauthenticated access if it exists. 3. CORE WORKFLOWS This is the heart of the blueprint. Every significant user journey, step by step, from entry to completion. For each step, state what the user does, what the system does in response, what is validated, and what happens when the step fails, is cancelled, or is left incomplete. Be exhaustive. A rebuilder should be able to follow these like a script. 4. DATA MODEL Every entity: its fields, their types, defaults, and constraints; the relationships between entities; uniqueness and referential rules; and the REASONING behind any non-obvious modelling choice. Where a field encodes a rule (a status enum, a soft-delete flag, an ordering column), say what the rule is. 5. BUSINESS RULES AND EDGE CASES The awkward parts, stated precisely. Concurrency and conflicting edits, partial or inconsistent state, empty and boundary conditions, limits, rounding, time zones, ordering, anything you had to think about twice. Give the exact rule and, where useful, a concrete example. 6. INTERFACE AND INTERACTION Screen by screen or view by view. What is on each, what every control does, the states each view can be in (loading, empty, error, success), keyboard shortcuts, and any interaction that is not obvious from a static description. Describe behaviour and intent, not exact pixels or colours, unless a specific measurement is load-bearing. 7. AUTHENTICATION, AUTHORISATION AND SECURITY How users authenticate, how access is granted and checked, what is protected and from whom, how input is validated and sanitised, and any security property a rebuild must not lose. Be explicit about anything that would be a vulnerability if done naively. 8. EXTERNAL INTERFACES AND CONTRACTS Any API the app exposes or consumes, file formats it reads or writes, imports and exports, webhooks, background jobs, scheduled tasks, and third-party integrations. Give exact request and response shapes, field names, formats, and error behaviour. These are contracts; a rebuild must match them byte for byte where other systems depend on them. 9. TECHNOLOGY STACK What THIS build used: language, framework, database, key libraries, runtime. Mark this clearly as INFORMATIONAL. A rebuilder may retarget it, and should be able to. Call out separately anything that is a genuine hard requirement (a specific format, protocol, or algorithm the app must implement) versus a free choice (which web framework, which CSS approach). 10. NON-OBVIOUS DECISIONS A dedicated section for the judgment calls that would otherwise be invisible in a rebuild: where you chose this approach over the obvious alternative, and why. This section is the difference between a blueprint and a generic prompt. Be generous with it. RULES FOR WRITING IT - Be precise and complete over concise. This document must be VERY detailed. Length is expected; vagueness is the failure mode. - Prefer explicit rules, exact values, and concrete examples over prose. State field names, formats, limits, and defaults literally. - Where a choice was deliberate, state the choice AND the reason. - Do NOT paste source code or dump whole files. Specify behaviour and contracts so the code can be regenerated, not copied. Short snippets are fine only where a format or algorithm needs to be exact. - Where something in the current code is genuinely arbitrary, say so, so the rebuilder knows they have freedom there and does not preserve an accident as if it were a decision. - Write for an agent that is competent but has zero prior knowledge of this project or its domain. Define the domain terms. PORTAL LISTING METADATA (include this) Begin app.md with a YAML frontmatter block, before the title and before any prose. Athena Lab reads it to prefill the upload form, so the author does not retype the stack, category, licence and so on. This block is metadata for the portal, NOT part of the blueprint. A coding agent rebuilding the application should ignore it. The leading and trailing --- fences are the standard signal to skip a frontmatter block, and the comment states it outright. Use exactly these keys. Omit any key you genuinely cannot determine rather than guessing. `category` must be one of the portal categories and each `platforms` entry must be from the portal platform list, both listed below; if nothing fits, omit that key. Portal categories: Booking & Scheduling, Inventory & Stock, E-commerce & Payments, Finance & Invoicing, CRM & Client Management, Support & Helpdesk, Marketing & Outreach, Projects & Task Management, Learning & Education, Dashboards & Reporting, Content & Publishing, Marketplaces & Multi-vendor, Internal Tools & Admin, Media & File Processing, Developer & Technical Tools Portal platforms: Web, Mobile, Desktop, Server, CLI Emit it in exactly this shape: --- # Athena Lab listing metadata. Not part of the blueprint; ignore when building. title: summary: description: "" version: 1.0.0 category: platforms: [] licence: stack: [] tested_with: [] tags: [] --- The blueprint itself begins after the closing fence. OUTPUT Produce one markdown file named app.md, opening with the metadata block above and then the full specification. If the specification is large enough that a single file harms clarity, use app.md as the root entry point that describes the whole application and links out to additional markdown files for detailed sections. Keep app.md as the front door either way, and keep the frontmatter on app.md. Do not summarise. Specify.