Flight Deck 针对的是智能体长会话中“对自身任务的记忆最先丢失”的问题：工具输出滚走、上下文被摘要，剩下的是磨掉操作细节的看似合理的叙述，而工作在继续运行，智能体的认知却悄悄过期，导致重跑已付费作业、凭记忆报数字或忘记某事被阻塞。其解法不是更好的记忆，而是把状态写在不会被摘要的地方。
核心文件：STATUS.md 是仪表盘，原位重写，只描述现在，绝不追加。包含 RUNNING NOW（进程号、日志路径、在等待什么）、QUEUED（按顺序）、BLOCKED（原因及解锁条件）、HELD（已完成但有意未发布的工作及待决策人）、AWAITING（自己无法回答的问题）、DONE（每项一行，避免重做）、EVIDENCE（带实际数字的测量）、STANDING RULES（新读者否则会违反的约束）。LOG.md 是飞行记录器，只追加，解释原因：决策、纠正、死路及理由。两者用途不同，都不可少。机制不明显时，可选提交一份 how-it-works 文档，属持久内容，应纳入版本控制。
所有者页面面向不盯会话的人，使其无需读记录就能知道工作进展和需要自己做什么。顶部简短显示所处阶段与里程碑，以及刚完成、进行中、下一步各最多三行。只列需要他们的事项（决策、单向门放行、仅本人能做的任务），不列状态、回执或已完成工作。每项说明需要什么、在哪里、为何只能由他们做、推荐选项（预选）及答复后的结果。有 Artifact 工具时，首轮即按 references/owner-page.md 和 assets/owner-page.html 构建带数据库的 artifact；无该工具则用 OWNER.md。页面上的“放行”不能替代执行环境对单向门的权限检查，放行须在聊天中输入。
处理答复的顺序：先记录决策（产品决策日志、STATUS.md 的 QUEUED、LOG.md 的原因），再一次写入删除事项及其答复（门禁只删答复，保留至聊天中放行），然后行动（门禁须聊天放行后），最后在聊天中一行确认。因保存不会通知，需在固定节点检查：阶段边界、构建或评审运行期间、结束回合前、压缩后以及对方称已答复时。
关键规则是每次状态变化（作业启动、完成、失败、发布、决策落地、变为阻塞）立即更新 STATUS.md，而非事后或按需；八成真实的状态文件比没有更糟。保持简短以免失真。证据行价值最高：探针结果、基准数字、结论、成本、“测过 X 不可行”，丢失证据会带来重跑付费实验或误报数字的代价。
文件按工作领域而非仓库配对：一个仓库三项无关工作需三对，三个仓库服务一项工作只需一对。放在临时或工作目录等能存活但不污染之处，并交叉链接。压缩后先读 STATUS.md，略读 LOG.md 最近决策，再核实列为运行中的进程确实在运行，以现实为准修正文件。
不适用场景：短会话、单次任务、能轻松放进一个上下文窗口的工作，开销真实且无意义。判断有效的标准是：压缩后读一次状态板即可知道什么在运行、被什么阻塞、等谁，且每行都与磁盘和运行状态一致。