最初的描述
« 我是一名石膏板隔墙工，带两名员工，同时进行约十个工地。每个工地都有一个客户、一个地址、一个报价金额和一个状态：准备中、进行中、等待客户、已完工、已开票。我记录工日以及每个人的工时，还有消耗的材料。我想看到哪些在进行、哪些在拖延，以及本月的可开票总额。 »
生成前已确认的方案
描述被翻译成一份在生成前供你审阅的方案。对 ChantierClair 而言：四个实体——工地、客户、工日、消耗材料——按提案所述关联：一个工地归属于一个客户，一个工日和一份材料挂在一个工地上。
文本中使用的五个状态（准备中、进行中、等待客户、已完工、已开票）原样带入方案，并将成为应用的徽章与筛选器。所宣布的指标——进行中的工地、本月工时、可开票金额——在任何生成之前就已列入方案。
- 实体：工地、客户、工日、消耗材料
- 关系：工地 → 客户；工日 → 工地；材料 → 工地
- 状态：准备中、进行中、等待客户、已完工、已开票
- 指标：进行中的工地、本月工时、可开票金额
导航：工地优先
侧边栏列出各板块：仪表盘、工地、客户、工日、材料。工地列表是核心屏幕：每一行显示工地名称、客户、地址、以货币格式呈现的报价金额，以及以彩色徽章表示的状态——「等待客户」不会与「进行中」混淆。
状态筛选器完成周一早晨的分拣：一次点击只看进行中的，另一次点击把尚未开票的「已完工」单独挑出。按名称或客户搜索，按金额或日期排序：是列表取代文件夹，而非反过来。
工地档案，含工日与材料
「Perrin 宅 — 扩建」工地的档案汇集了原本分处三地的内容：工地信息（可点击的客户、地址、18 400 € 的报价、状态），随后在下方是两张关联的表格——带日期的工日及每名员工的工时，以及带数量的消耗材料。
历史自上而下阅读，如同一本施工日志：一眼便知工地于 6 月 3 日开工，已投入 74 小时，以及安装了什么。正是关系型数据库把一切挂到正确的工地上——无需抄录。
录入一个工日
「新建工日」表单很快，因为傍晚在料场没人会写报告：工地从下拉框中选取，日期预填，工时以数字录入，一个备注字段承载有用的细节（「龙骨完成，明天封板」）。
这次录入喂养其余一切：工地档案、仪表盘上本月的工时总计。录入一次，只在正确的地方。
仪表盘：老板的问题，化为数字
仪表盘回答提案中的问题：有多少工地在进行中，有多少在等待客户（那些拖延的），本月工作的总工时，以及可开票金额——已完工但尚未开票的工地报价之和。
按状态划分的工地分布补全这些方块：订单簿的形态一眼可读。所有这些数字都在每次显示时于数据库上计算——一个工地一转为「已完工」，可开票金额随之变动。
演示数据：一家可信的企业
ChantierClair 交付时附带数月的模拟活动：约十来个名称可信的工地（「Dubois 外墙翻新」「Rue des Tilleuls 阁楼」），分布在五个状态上，回头客户，从三月到六月分布的工日，以及一致的材料消耗。
在充实的屏幕上评判工具：筛选器有可筛之物，仪表盘显示可信的金额。随后演示数据被清除。应用运行在自己的专属 URL 上，可在工地用手机查看，源代码可完整导出（ZIP、GitHub）。