Turn your app into a blueprint

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: <the application name>
summary: <one line, under 300 characters, shown on listing cards>
description: "<a short paragraph on one line, no line breaks>"
version: 1.0.0
category: <one of the portal categories above>
platforms: [<one or more of the portal platforms above>]
licence: <an SPDX id such as MIT, Apache-2.0, or Proprietary>
stack: [<languages, frameworks and libraries this build used>]
tested_with: [<coding tools you verified the build with, e.g. Claude Code>]
tags: [<capability keywords: what it does and its key features>]
---

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.