译文
译自西班牙语原文，以原文为规范文本。 状态：草稿，待人工审校。如有歧义，以西班牙语原文为准。
文件、目录与命名¶
基于 MILPA 0.1 的现行应用指南。不规定通用的目录树。
结构有助于找到知识，并知道哪些内容可以更改。从你需要定位的功能出发，而不是从复制别的项目的目录树出发。
七项功能，而不是七个文件¶
MILPA-R-006 的核心包含这些功能。每一项都有一个可识别的位置；具体名称属于配置。
| 功能 | 使人能找到什么 |
|---|---|
| 清单 | 项目的身份、范围和负责人。 |
| 面向读者的入口 | 项目是什么，以及从哪里开始。 |
| 来源与关联 | 知识的出处和已声明的关系。 |
| 智能体指令 | 智能体运行时适用的规则。 |
| 文档索引 | 从概览到细节的地图。 |
| 决策 | 决定了什么、由谁决定、基于哪个修订版本。 |
| 单独存放的临时材料 | 不会与已被接受文本相混淆的草稿和探索。 |
项目可以把它们分散到多份文档中，也可以把其中几项合并到一份文档里。本指南不会把 README.md、AGENTS.md、SOURCE.md、docs/、plans/ 或 .asilo/ 变成强制的通用名称。
从概览到细节排列¶
一个简短的入口说明目的、范围和下一步。索引指向各个主题；主题再链接到决策、要求和证据。这条路径避免为了回答一个小问题而加载整个项目。
作为练习，构建一张“功能 → 实际位置 → 负责人 → 审查”的表。检查这些位置确实存在，并且索引没有把一份计划当作已经实现的内容来链接。这张表是阅读辅助，不是已被接受的方法论模式。
先声明名称再使用¶
MILPA-R-005 要求已声明并受版本管理的保留词汇。保留名称保持其含义；新名称需要在该词汇表中登记一次变更。产品或领域的专有名称不在其内。
此前的列表和某种语言的惯例，并不因此成为通用词汇。基础词汇的内容和版本有待具体化；请参见筹备中的配置。
整合而不合并¶
当两个项目相关联时，MILPA-R-007 要求在两端都声明提供方、消费方、契约和版本、跨越边界的数据、负责人、状态和证据。共享一个目录或一个品牌，并不能证明实现了集成。对于已发布的版本，本地路径不能成为唯一的关联机制。
结构变更要保留其来源以及为其提供理由的决策。如果规则互不相容，请依据 MILPA-R-008 登记这一冲突；不要仅靠重命名目录来解决它。
一张功能地图¶
建筑物里的标识指明每项活动发生在哪里。类似地，结构使人能够定位来源和决策。房间的名称可以改变；它的功能依然可以辨认。这张地图不施加任何权限。
术语表。