---
phase: screens
kind: reference
---

# Post-check — Self-check before writing `screen.md`

Run this checklist mentally on every screen before you Write the section's
`screen.md`. Catching an issue here keeps the spec consistent with the data
model, RBAC and use cases the screens depend on. The deep audit
(`/ba-audit-screens`, rules SCR-001..025) re-checks all of this against the tree
and writes a verdict — but a clean self-check avoids a rework round-trip.

## Blocking checks (fix before writing)

1. **Unique code**: every screen has a unique `code` of the form
   `SCR-{APP}-…-NNN` within the section's `screen.md`.
2. **Menu reference**: the application / module / section the screen belongs to
   exists as a folder in the `.smartstack/ba/` tree (the folder path is the code
   chain). A home page's scope matches its type:
   - `SmartAppHome` is app-scoped (no module/section segment in the code).
   - `SmartModuleHome` is module-scoped (no section segment).
3. **Entity reference**: `SmartListView`, `SmartForm`, `SmartKanban`,
   `SmartCard` name a non-empty entity, and that `ENT-…` code is found by Grep
   in the module's `entité.md`. `SmartDashboard` and the home types may omit the
   screen-level entity but each widget MUST name its own.
4. **Config shape**: the per-screen bullets match the type (see
   `references/smartcomponents.md`):
   - `SmartListView`     → ≥1 column, optional filters.
   - `SmartForm`         → fields OR tabs non-empty; related tabs only in
                           `edit`/`detail`.
   - `SmartDashboard`    → ≥1 widget.
   - `SmartKanban`       → a status field + ≥2 columns (keys = the status
                           enum values VERBATIM from `entité.md`) + a title
                           field. The block stays the authored form — the PRD
                           folds it into the LIST pagespec (derive-kanban-spec).
   - `SmartCard`         → a title field.
   - `SmartAppHome`      → ≥1 widget + ≥1 quickLink; app-scoped.
   - `SmartModuleHome`   → ≥1 widget + ≥1 quickLink; module-scoped.
   - `SmartSectionHome`  → ≥1 widget + ≥1 quickLink.
5. **Lookup integrity**: every column or field of type `lookup` names a
   non-empty entity that exists in the data model.
6. **Badge/enum integrity**: every `badge` column and every `enum` form field
   names a non-empty `options` set.
7. **Column attributes exist**: every `SmartListView` column references an
   actual attribute of the screen's entity. For nested paths like
   `department.name`, the head segment (`department`) must be an attribute.
8. **Form attributes exist**: every `SmartForm` field references an actual
   attribute of the screen's entity.
9. **Filter validity**: every list filter of type `lookup` names an entity, and
   every filter references a valid entity attribute.
10. **Action permission references**: every action permission referenced exists
    in the module's `rbac.md` (Grep it).
11. **Navigation targets exist**: every row-click / card-click / quickLink /
    related-tab target references a screen `code` that exists in the tree (this
    `screen.md` or an already-written sibling). Broken targets fail SCR-008.
12. **Related-tab consistency**: do NOT eyeball this one — run the colocated
    CLI in validate mode (`cli/derive-related-tabs`, `{"mode":"validate"}`) and
    fix every `err`. It checks deterministically that each related tab has
    (a) a related entity that exists in the data model (RTV-001), (b) a
    relationship FK on that entity pointing toward this screen's entity
    (RTV-002), (c) a target that is a `SmartListView`/`SmartCard` for that
    related entity (RTV-003), (d) a valid `affichage` and unique keys
    (RTV-006/008), and (e) no related tabs on a `create` form (RTV-005).
13. **Home-page scope**: a `SmartAppHome` code carries no module/section
    segment; a `SmartModuleHome` code carries no section segment.

## Non-blocking warnings (surface to the user)

- **Missing use cases**: a screen with no linked use case is suspicious — at
  least one use case should justify any UI surface. Warn but proceed.
- **Computed not readonly**: a SmartForm field whose entity attribute is
  computed must be `readonly` in edit/detail. Fix it.
- **Workflow without kanban**: an entity with a `status` enum ≥3 options and no
  SmartKanban — the board is highly recommended (as a second screen in the entity's
  `*-list` section, never its own section). Warn.
- **Missing related tabs**: a `SmartForm` in `edit`/`detail` whose entity has
  ≥1 incoming 1:N relation but no related tab AND no `Sans onglets liés`
  justification marker is now a **blocking** audit error (SCR-009, err — the
  fiche client Client ⟷ Factures, Contacts, Litiges is the canonical 360
  example). The CLI's validate mode surfaces it as RTV-007 — fix or justify
  before writing.
- **Missing app/module home**: an app with ≥2 modules but no `SmartAppHome`, or
  a module with ≥2 sections but no `SmartModuleHome`. Warn (SCR-006/007).

## Self-test sequence

Before writing, walk through these questions:

1. Did I read the menu tree (`Glob .smartstack/ba/**/index.md`)? Does every
   screen sit under a folder that exists? Did I keep home-page scope correct?
2. Did I read the module's `entité.md`? Does every named entity exist (Grep
   `ENT-…`)? Do all column/field names match attributes on those entities? Do
   the related-tab entity + FK map to real entities and FKs?
3. Did I read the module's `rbac.md`? Do the screen and action permissions
   appear there?
4. Did I read the section's `use-case.md`? Are my linked use cases real `UC-…`
   codes from it?
5. For every application with ≥2 modules, did I propose a `SmartAppHome`?
6. For every module with ≥2 sections, did I propose a `SmartModuleHome`?
7. For every section with ≥3 resources or `*-home`/`*-overview` naming, did I
   consider a `SmartSectionHome`?
8. For every `SmartForm` in `edit`/`detail` whose entity has incoming 1:N FKs,
   did I propose related tabs?
9. For every entity with a `status` enum ≥3 options, do I have a SmartKanban in
   that entity's `*-list` section (a second screen, not a separate board section)?
10. Did I respect the type-mapping table for every column and field?
11. Did I keep computed attributes `readonly` in edit forms and absent in create
    forms?
12. Did every navigation target reference an existing screen `code`?

If any answer is "no" or "unsure", refine before writing — or surface the gap to
the user via AskUserQuestion.