[Feat]: Add a task-state-invariants agent skill for sibling-surface propagation
維護者通常 2 天內回覆
評估
這個 Issue 還沒有評估資料。
描述
Is your feature request related to a problem? Please describe
The agent rule layer in this repo is good at three things: code style
(docs/ai/coding_conventions.md), the pre-done gate
(docs/ai/mandatory_checks.md), and post-mortem capture
(.agents/skills/mistake-reflection). What none of them state is which
surfaces a task-state write has to reach. That gap keeps producing the same
class of defect: a value that is correct on one surface and missing or stale
on another.
Recent instances, all in this class:
- #1276 (closed):
status.timestampwas mapped by
src/a2a/compat/v0_3/conversions.py(JSON-RPC/REST compat) but not by
src/a2a/compat/v0_3/proto_utils.py(gRPC compat) — the same field appeared
or disappeared depending on transport. - #1331 (open): a framework-written
FAILEDstatus carried no
status.timestamp, andsrc/a2a/server/tasks/database_task_store.py:152-157
deriveslast_updatedfrom it, so the row persistedNULLand dropped out
ofListTasksordering. - #1188 (open) / #1409 (open): the handler resumes or returns from a snapshot
that disagrees with what later reaches the store and the stream. - #1206 (closed as stale) → #1411 (open):
contextIdinference makes events
disagree with the storedTask. - Review findings on #1346: stamping the local copy after
task.status.CopyFrom(event.status)leaves the published event unstamped
(src/a2a/server/tasks/task_manager.py:285), and theCANCELEDpaths at
src/a2a/server/agent_execution/active_task.py:971-973keep the previous
state's timestamp. These were caught by review, not by any documented rule.
The same confusion shows up in the discussion forum, where it has no issue
tracker to land in: #248 ("Should Message events terminate…", 6 comments),
#435, #40 ("What's the purpose of EventQueue?"), and the multi-replica thread
#1224 / #336.
Describe the solution you'd like
A new skill, .agents/skills/task-state-invariants/SKILL.md, in the same
shape as mistake-reflection (trigger list → procedure → anti-patterns),
covering:
- the invariant set, each claim anchored to current
main(terminal states
need a timestamp; stamp the event beforeCopyFrom;CopyFrominherits
the old timestamp; push delivery is best-effort; zero events means a hung
caller; store and stream must agree; v0.3 compat has two independent
mappers; continuation identity is inferred per spec §3.4.3); - a sibling-surface checklist to run before declaring such a change done
(persisted store, streaming subscribers, push notification, cluster
task_eventstable, both compat mappers); - a test map naming the existing file per surface, so coverage lands where
the surface is; - the evidence a PR in this area should carry, consistent with
docs/ai/evidence_rules.md.
Plus a one-line pointer in AGENTS.md "Mandatory workflow". That pointer
matters: AGENTS.md is the only file in the repo that routes to
.agents/skills/, so a skill without a route is never loaded.
Describe alternatives you considered
- A
docs/ai/rules page. Rejected as the primary form:docs/ai/*is
read at task start, while this knowledge is only useful at the moment you
touch a status write — which is howmistake-reflectionis structured.
Happy to have both if maintainers prefer the rule text to live indocs/ai
with the skill as a thin pointer. - Encoding it only in tests. Partially useful, but tests cannot tell a
change agent which sibling surface they forgot. - Fixing each bug as it arrives. Six-plus in about six weeks suggests the
per-bug loop is not converging.
Additional context
Scouting the rule layer, .agents/skills/ has exactly one skill today and it
was introduced internally by #1059 — I found no precedent for an externally
contributed skill, so raising this first rather than assuming. A draft
implementation (skill + the one-line router pointer, markdown-only, no
runtime code) is ready and filed as a PR linked to this issue. Easy to trim:
drop the AGENTS.md line, or scope the skill to the compat-mapper and
timestamp rules only.
Code of Conduct
- I agree to follow this project's Code of Conduct
- 主要語言
- Python
- 星號
- 2.2k
- 分支
- 532
- 平均合併
- 3 天 2 小時
- 30 天內合併 PR
- 46
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
a2aproject/a2a-python 的其他 Issue
-
[Bug]: `A2A-Version` validation ignores minor versions and the query parameter可能已有人在做 @rohityan 於 72 天前認領。 未關閉component: server status:awaiting response status:stale
難度 2/5 1-3 小時 新手友好度 75/100
a2aproject/a2a-python#1204 · 4 則留言 · 已指派 1 人 ·
維護者通常 2 天內回覆
-
[Bug]: REST task/request id sanitization可能已有人在做 @Linux2010 於 131 天前認領。 未關閉maintainers-only
難度 2/5 1-3 小時 新手友好度 65/100
a2aproject/a2a-python#805 · 1 則留言 ·
維護者通常 2 天內回覆
-
v0.3 REST and gRPC clients send blocking requests as non-blocking可能已有人在做 @rohityan 今天認領。 未關閉
a2aproject/a2a-python#1428 · 已指派 1 人 ·
維護者通常 2 天內回覆
-
Compat REST client drops security from the v0.3 extended agent card可能已有人在做 @ConnorMoss02 於 1 天前認領。 未關閉component: client status:awaiting response
a2aproject/a2a-python#1418 · 1 則留言 · 已指派 1 人 ·
維護者通常 2 天內回覆
-
[Bug]: taskId-only continuation still fails required contextId inference in SDK 1.3.0 (follow-up to #1206)可能已有人在做 @Iwaniukooo11 於 2 天前認領。 未關閉component: server status:awaiting response
a2aproject/a2a-python#1411 · 1 則留言 · 已指派 2 人 ·
維護者通常 2 天內回覆
查看 a2aproject/a2a-python 的全部 Issue
相似的 Issue
-
community enhancement good first issue
難度 2/5 1-3 小時 新手友好度 86/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 77/100
Hochfrequenz/sapgui.mcp#1039 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 88/100
didi/helixharness#18 ·
-
難度 2/5 1-3 小時 新手友好度 75/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 68/100
dataforgoodfr/democracy-watch#46 · 1 個 reaction ·