Work Item Progress Review
Follow the evidence-based review methodology of aha-links, using TE space permissions, the three-state model, and independent archiving. First read Work Item Operations and the Collection Contract. Do not guess work item, space, or assignee IDs.
When this run has bound work items, first follow Execution Snapshot and Live Context to read the execution snapshot for this run, then collect the latest review or cycle facts using the following workflow; describe the two sources separately. When there are no bound items, use only the scope explicitly specified by the user.
Read Facts
bash
ae-cli things +detail --agent-space-id <space-id> --id <thing-id> --format json
ae-cli things +digest --agent-space-id <space-id> --format json
ae-cli things +digest --agent-space-id <space-id> --thing-ids <id-a>,<id-b> --format json
The scope supports only the current space, a specific assignee, or an explicit set of work items. Do not fold in watchlists or Feishu group scopes. For large scopes, screen first, then conduct in-depth reviews in batches of at most 20 items, and disclose the number screened and reviewed in depth.
You must check
,
,
, and
. Missing fields indicate an incompatible contract. If results are truncated or unreadable, draw conclusions only from the facts covered; do not describe the first 100 items as the full dataset. When
changed_during_collection
is present, reread the affected items;
data still does not constitute a strict point-in-time snapshot. Explicitly disclose unread attachments, private history, and any missing initial objectives.
Review Order
- Goals and acceptance: Determine whether they are clear, reasonable, and verifiable; compare the earliest record with the current goal. If the original goal cannot be reconstructed, review only the current goal.
- Scope drift: Determine whether goal changes were explicitly recorded; do not treat later conclusions as the original goal.
- Substantive updates: Results, changes, blockers, or explicit next steps count as progress. Progress records are candidates for verification; placeholders, repeated statuses, notes, and title-only changes do not reset the reminder cadence. Collected counts are only candidates, and the model must still verify whether the body contains a substantive update.
- Ownership: Verify that assignees and collaborators are available, and that next steps are explicit in the description and progress updates.
- Completion evidence: Verify that deliverables are accessible and satisfy the acceptance criteria; do not claim that unread files have passed acceptance.
Honor explicitly agreed cadences.
means incomplete and does not distinguish between not started and in progress. When no cadence has been agreed, report only the last record timestamp and do not infer stagnation. For
, check the recorded pause reason and resume conditions. State only “no update recorded,” and do not infer that “there has been no progress.”
Every cited timestamp must include its time zone. When determining calendar days in Asia/Shanghai, first correctly convert the ISO Z/offset value rather than merely stripping the suffix. For example,
corresponds to 12:50 in Shanghai. If conversion is not possible, retain the original UTC value and disclose the limitation.
Output and Boundaries
Assign one of the following ratings: Healthy / Needs attention / High risk / Insufficient information. Include the goal baseline, evidence with work item links and dates, impact, confidence, and no more than three priority actions. For a space-level review, present common issues first, followed by item-by-item summaries. Do not evaluate individual performance or create an aggregate score.
Diagnose only by default; do not change statuses or assignees. When the user explicitly requests specific changes, reread the current version before applying them, and do not repeatedly request the same authorization. For inferred changes, first provide a proposal for confirmation. Do not automatically send messages or create scheduled tasks.
File evidence:
and
automatically paginate to collect asset associations. Files with
or
do not count as usable deliverables. Even when a file is
, this only means that its reference is accessible; it does not mean that its contents were read or accepted. Disclose unread files and the boundaries of non-transactional collection. Read private-session sources only when the current user has permission. Reports must cite shared work item facts and must not automatically expose private history.