Erlyc Erlyc

Specification

What this screen does

The Specification page holds the written specification generated from your locked boards. It keeps every version, scores each one with an independent critic, and offers downloads in Markdown, HTML, and PDF. Alongside the document itself you can switch to the Screen Map tab — a diagram of the application's screens and flows.

Typical workflow

  1. After Lock & generate specification on the last board, the first version appears here.
  2. Read the document top to bottom. The spec critic panel shows a quality score, a verdict, and how the score moved against the previous version.
  3. If something is missing or wrong, iterate: refine the underlying boards or request an improvement cycle, then compare versions — the changelog lists what changed between them.
  4. Use the version list to open or restore any earlier version.
  5. Download the version you are happy with as Markdown, HTML, or PDF — or the screen map as JSON.

The link check

Above the document, the page compares the specification's text with its data model. It reads the functional requirements, user journeys, screens, business rules, permissions and edge cases (edge cases feed the callout only, never a Mentioned in line), and lists where they disagree with the entities and fields the data model defines.

  • An issue is a disagreement the generated code would trip over: a key that points at an entity the data model doesn't list, or an entity this version dropped that the text still writes as code (Customer, customer_id). Issues sit in a warning callout headed "N issues between the text and the data model".
  • A note is worth a look but may be fine: the text says two entities are related and the data model doesn't link them directly, gives a status a value the data model doesn't offer, or still uses a dropped entity's name as a plain word; or the data model lists something twice. Notes stay behind Show N notes. When there are only notes, the page shows one muted line instead of a callout.

The check is advisory. Unlike the access-model callout, it has no fix button and spends no credits: correct the boards or request an improvement, and the next version is checked again. A finding in the text links to its requirement or section; a data-model finding names the entity and field instead.

Under every entity heading in the Data model section, a Mentioned in line links to each requirement, journey, screen, rule or permission that names that entity; past five links, +N more shows the rest. Not mentioned in the text means none of them names it: an entity the text forgot, or one it no longer needs. The user, role and permission tables every generated application has never get that line, and neither does a table that holds keys to two or more other entities and that nothing points at: link tables, and many log and line tables. Neither does an entity the text names only by its last word on its own, or only in an edge case: it shows no line at all.

A name counts in the singular or the plural, in any case, and written as code (PurchaseOrder, purchase_order_id). A partial mention is the entity's last word right after another word of its name, such as "test cases" for ReleaseTestCase; hover the link to see the words it matched. A role's name also links its profile entity: the Tutor role links TutorProfile. The last word on its own ("category" for ProviderCategory) never shows a link, and neither does a mention of the user, role or permission tables. A common word that names an entity (Status, Type, Order, Message) counts only when it is capitalised or written as code, so such an entity can show fewer mentions than you expect, and it never shows Not mentioned in the text. The line and the callout are never part of a download.

Examples & tips

  • The critic's score is a guide, not a gate. A small score dip on a version that fixed a real business mistake is still progress.
  • The specification is the single input for code generation: whatever is vague here will be guessed there. Names of roles, screens, and key fields are worth getting exact.
  • Ask questions about any paragraph via right-click — useful when a requirement reads ambiguously and you want the project agent's interpretation on record.