Codifica Protocol Agent
You are operating in a repository that uses the Codifica protocol (v0.2) — a file-based protocol for coordinating work between humans and AI agents.
Codifica uses plain text files committed with the code. There is no external service, no API, no database. Git is the audit log.
Before doing any work
- 1. Read
codifica.json at the repo root - Read the spec file it references (the
spec field — typically codifica-spec.md) - Read ALL state files matching the
state field (may be a string, glob, or array)
Do not proceed without reading the spec.
If codifica.json does not exist in the repo, this protocol does not apply — work normally.
Understanding codifica.json
CODEBLOCK0
Key fields:
- -
state — path to the state file(s). May be "work.md", "work/*.md", or an array like INLINECODE8 - INLINECODE9 — may be a string (
"strict") or an object with allowed_agents, file_scope, max_concurrent_tasks_per_agent, stale_claim_hours, and INLINECODE15
If rules is an object, check:
- -
allowed_agents — if non-empty and your agent name is not listed, stop and ask a human - INLINECODE18 /
file_scope.exclude — do not modify files outside the allowed scope - INLINECODE20 — do not claim more tasks than this limit
Finding work
Scan all state files for tasks where:
- -
state is INLINECODE22 - INLINECODE23 matches your agent name (
agent:<your-name>) or is INLINECODE25 - All
depends_on tasks have INLINECODE27
Pick by priority: critical > high > normal > low.
Among equal priority, prefer tasks with no depends_on (leaf tasks first).
Claiming a task
Before starting work, you MUST claim the task in a single atomic commit:
- 1. Set INLINECODE33
- Set INLINECODE34
- Set INLINECODE35
- Add a
state_transitions entry recording the claim
Commit all these changes together. If you are working with a remote, push immediately. If the push fails (another agent claimed first), do NOT start work — pull, re-evaluate, and pick a different task.
An unassigned task in in_progress is a protocol violation.
Reading context before starting
Before starting a task, read its context field:
- -
context.files — read these files for background - INLINECODE41 — read
execution_notes from these prior task IDs - INLINECODE43 — hard rules beyond acceptance criteria
- INLINECODE44 — free-form guidance from the human
If the task has depends_on, also read the dependency tasks' execution_notes (especially the summary) and artifacts for handoff context.
Doing the work
Follow the task's acceptance criteria. Respect any context.constraints. Work within the file_scope defined in codifica.json.
Recording completion
When you complete work, update the task in the state file:
- 1. Add an
execution_notes entry:
CODEBLOCK1
- 2. Record any files you produced in
artifacts:
CODEBLOCK2
- 3. Move the task to the appropriate next state:
- For
build tasks:
in_progress →
to_be_tested
- For other types (
test,
investigate,
followup):
in_progress →
done (may skip
to_be_tested)
- Set
completed_at: <ISO-8601> when moving to INLINECODE65
- 4. Add a
state_transitions entry:
CODEBLOCK3
- 5. Commit with a message referencing the task ID: INLINECODE67
Rules you MUST follow
- - Pull before reading state files. Pull before writing changes.
- Claim tasks with a single commit before starting work.
- If your claim push fails, do not start — pick a different task.
- Never edit
human_review sections. - Never delete or modify files in
assets/. - Only the task owner may move a task from
to_be_tested to done. - Never move tasks to
blocked or rejected — only humans may do this. - Never reclaim stale tasks from other agents — only humans may reclaim.
- Do not start tasks with unmet
depends_on. - Include a
summary (single line, max 120 chars) on your closing execution note. - Record artifacts produced by your work.
- Set
completed_at when moving a task to done.
Requesting a block
If you discover a genuine blocker (missing dependency, failing test, ambiguous requirement):
- - Add a note to
execution_notes explaining the blocker and recommending the task be blocked - Do NOT move the task to
blocked yourself — only humans may do this
Answering questions about work
When asked about what work has been done (by you or other agents):
- - Scan state files for tasks matching the query (by
owner, state, labels, completed_at) - Read the
summary field on closing execution_notes for quick answers - Drill into full
note text and artifacts when more detail is needed - Use
completed_at and labels to filter by time and domain
This is the structured alternative to reading chat transcripts.
Conflicts
If your push fails due to a Git conflict:
- 1. Pull the latest state
- Re-evaluate whether your changes still apply
- Retry or yield to human resolution
Conflicts on the same task should be escalated to a human.
Task states reference
CODEBLOCK4
Only humans may move tasks to blocked or rejected.
Only humans may reopen tasks from rejected.
Codifica 协议代理
你正在操作一个使用 Codifica 协议 (v0.2) 的仓库——这是一种基于文件的协议,用于协调人类与AI代理之间的工作。
Codifica 使用随代码一起提交的纯文本文件。没有外部服务,没有API,没有数据库。Git 就是审计日志。
开始工作前
- 1. 读取仓库根目录下的 codifica.json
- 读取它引用的规范文件(spec 字段——通常是 codifica-spec.md)
- 读取所有与 state 字段匹配的状态文件(可以是字符串、通配符或数组)
不读取规范文件不得继续。
如果仓库中不存在 codifica.json,则此协议不适用——正常工作。
理解 codifica.json
json
{
protocol: codifica,
version: 0.2,
spec: codifica-spec.md,
state: work.md,
assets: assets/,
rules: strict
}
关键字段:
- - state — 状态文件的路径。可以是 work.md、work/*.md 或类似 [work/active.md, work/done.md] 的数组
- rules — 可以是字符串 (strict) 或包含 allowedagents、filescope、maxconcurrenttasksperagent、staleclaimhours 和 custom_types 的对象
如果 rules 是对象,请检查:
- - allowedagents — 如果非空且你的代理名称不在列表中,停止并询问人类
- filescope.include / filescope.exclude — 不要修改允许范围之外的文件
- maxconcurrenttasksper_agent — 不要认领超过此限制的任务
寻找工作
扫描所有状态文件,查找满足以下条件的任务:
- - state 为 todo
- owner 匹配你的代理名称 (agent:<你的名称>) 或为 unassigned
- 所有 depends_on 任务的状态为 done
按优先级选择:critical > high > normal > low。
同等优先级下,优先选择没有 depends_on 的任务(叶子任务优先)。
认领任务
在开始工作前,你必须在一次原子提交中认领任务:
- 1. 设置 state: inprogress
- 设置 owner: agent:<你的名称>
- 设置 claimedat:
- 添加记录认领的 state_transitions 条目
一起提交所有这些更改。如果你正在使用远程仓库,立即推送。如果推送失败(另一个代理先认领了),不要开始工作——拉取、重新评估并选择不同的任务。
in_progress 状态下的 unassigned 任务是违反协议的。
开始前阅读上下文
在开始任务前,阅读其 context 字段:
- - context.files — 阅读这些文件以了解背景
- context.references — 从这些先前任务ID中读取 execution_notes
- context.constraints — 超出验收标准的硬性规则
- context.notes — 来自人类的自由格式指导
如果任务有 dependson,还要读取依赖任务的 executionnotes(特别是 summary)和 artifacts 以获取交接上下文。
执行工作
遵循任务的 acceptance 标准。尊重任何 context.constraints。在 codifica.json 中定义的 file_scope 内工作。
记录完成
完成工作时,更新状态文件中的任务:
- 1. 添加 execution_notes 条目:
yaml
execution_notes:
- by: agent:<你的名称>
note: |
你做了什么工作的描述。
summary: 单行,最多120字符,可快速浏览的答案
timestamp:
provenance:
session_id: <你的会话ID(如果有的话)>
- 2. 在 artifacts 中记录你生成的文件:
yaml
artifacts:
- path: src/feature/new-file.ts
type: code
- path: assets/TASK-ID/output.csv
type: csv
- 3. 将任务移动到适当的下一状态:
- 对于 build 任务:inprogress → tobe_tested
- 对于其他类型(test、investigate、followup):inprogress → done(可以跳过 tobe_tested)
- 移动到 done 时设置 completed_at:
- 4. 添加 state_transitions 条目:
yaml
state_transitions:
- from: in_progress
to: tobetested
by: agent:<你的名称>
reason: 工作完成,准备测试
timestamp:
- 5. 提交时使用引用任务ID的消息:FEAT-101: implement login flow
你必须遵守的规则
- - 在读取状态文件前先拉取。在写入更改前先拉取。
- 在开始工作前用一次提交认领任务。
- 如果认领推送失败,不要开始——选择不同的任务。
- 永远不要编辑 humanreview 部分。
- 永远不要删除或修改 assets/ 中的文件。
- 只有任务所有者可以将任务从 tobetested 移动到 done。
- 永远不要将任务移动到 blocked 或 rejected——只有人类可以这样做。
- 永远不要重新认领其他代理的过期任务——只有人类可以重新认领。
- 不要开始有未满足的 dependson 的任务。
- 在关闭的执行记录中包含 summary(单行,最多120字符)。
- 记录你工作产生的工件。
- 将任务移动到 done 时设置 completed_at。
请求阻塞
如果你发现真正的阻塞因素(缺少依赖、测试失败、需求模糊):
- - 在 execution_notes 中添加说明阻塞因素并建议任务被阻塞的注释
- 不要自己将任务移动到 blocked——只有人类可以这样做
回答关于工作的问题
当被问及已完成的工作(由你或其他代理完成)时:
- - 扫描状态文件中与查询匹配的任务(按 owner、state、labels、completedat)
- 阅读关闭的 executionnotes 上的 summary 字段以快速获取答案
- 需要更多细节时深入查看完整的 note 文本和 artifacts
- 使用 completed_at 和 labels 按时间和领域进行筛选
这是阅读聊天记录的结构化替代方案。
冲突
如果你的推送因Git冲突而失败:
- 1. 拉取最新状态
- 重新评估你的更改是否仍然适用
- 重试或交由人类解决
同一任务上的冲突应升级给人类处理。
任务状态参考
todo → inprogress → tobe_tested → done
↓ ↑
blocked ──→ todo ──────────────┘
↓
rejected ──→ todo (仅人类可重新打开)
只有人类可以将任务移动到 blocked 或 rejected。
只有人类可以从 rejected 重新打开任务。