dialogue-acceptance-2026-04-17

Yomiya Dialogue Acceptance

Date: 2026-04-17 Scope: canonical workflow + runtime skill + local installed skill Method: fixture-by-fixture acceptance review against team-consensus/dev-workflow.md and runtime references Validator: python3 scripts/validate_yomiya_workflow.py Result: PASS

Summary

This pass checks whether the rewritten yomiya skill now behaves like a daily product-flow operator instead of a narrow Project operator.

Acceptance bar:

• daily reconciliation language must route to reconcile
• version scope questions must stay read-first
• release routes must lead with user-visible value
• Project auth must split read and write scopes
• archived items must be restored before edits
• technical-only changes must not dominate user-facing release copy

All eight current fixtures pass this bar at the spec and runtime-reference level.

Fixture Results

1. open_issue_but_delivered

Status: PASS Route: reconcile

Why:

• The new routing table treats “这个 issue 还开着但其实已经交付了” as daily reconciliation, not direct closure.
• The reconcile flow now forces the skill to compare user-visible value, delivery evidence, and tracking state before any write.

Expected first-screen structure:

1. 用户可见价值
2. 交付证据
3. 范围对账
4. 待执行写操作

Blocked behavior:

• no direct close based only on Project state
• no accidental promotion into release_pass

2. project_read_but_no_write_scope

Status: PASS Route: reconcile

Why:

• github-project-ops.md now separates read:project from project.
• The canonical doc explicitly says read-only inspection may proceed, but writes must stop at a pending-write summary.

Expected first-screen structure:

1. 用户可见价值
2. 交付证据
3. 范围对账
4. 待执行写操作

Blocked behavior:

• no pretending that reads imply writes
• no silent write failure

3. archived_item_needs_unarchive

Status: PASS Route: reconcile

Why:

• The canonical workflow and github-project-ops.md now both require unarchiveProjectV2Item before editing an archived item.

Expected first-screen structure:

1. 用户可见价值
2. 交付证据
3. 范围对账
4. 待执行写操作

Blocked behavior:

• no direct field edit on archived items
• no skipped restore step

4. user_visible_pr_without_issue

Status: PASS Route: reconcile

Why:

• The workflow now explicitly says user-visible PRs without issues must be flagged for backfill instead of being omitted.
• Release routes inherit the same rule during scope alignment.

Expected first-screen structure:

1. 用户可见价值
2. 交付证据
3. 范围对账
4. 待执行写操作

Blocked behavior:

• no silent omission from product summaries
• no collapse into pure technical bookkeeping

5. technical_only_change_should_not_pollute_release_notes

Status: PASS Route: release_pass

Why:

• release-pass.md now says technical-only work defaults into the internal memo unless user experience changed.
• release-copy-and-aso.md keeps user-visible value ahead of implementation detail.

Expected first-screen structure:

1. 用户可见价值
2. 交付证据
3. 范围对账
4. 待执行写操作

Blocked behavior:

• no infra-heavy What’s New
• no fake user value invented from refactors

6. group_chat_requires_confirmation

Status: PASS Route: reconcile

Why:

• The safety doc now makes group-chat writes confirm-only.
• A bare “继续” is explicitly insufficient for confirm-level writes in group chat.

Expected first-screen structure:

1. 用户可见价值
2. 交付证据
3. 范围对账
4. 待执行写操作

Blocked behavior:

• no write execution on bare continue
• no skipped pending-write summary

7. daily_reconcile_trigger

Status: PASS Route: reconcile

Why:

• The route now exists as a first-class workflow and is explicitly listed in both the canonical doc and runtime entrypoint.

Expected first-screen structure:

1. 用户可见价值
2. 交付证据
3. 范围对账
4. 待执行写操作

Blocked behavior:

• no misroute to intake
• no misroute to issue_close

8. version_scope_query

Status: PASS Route: status_query

Why:

• “这个版本还有什么没收口” is now treated as a version visibility query, not as a release transition.
• The query template stays read-only and ends with one suggested next step.

Expected first-screen structure:

1. 用户可见价值
2. 交付证据
3. 未收口项
4. 建议下一步

Blocked behavior:

• no direct jump into release_pass
• no unconfirmed Project writes

What This Acceptance Proves

• The authority chain is now coherent.
• The missing daily reconcile workflow is now explicit.
• Release outputs are now ordered around user-visible value first.
• GitHub Project auth split is encoded in both policy and runtime references.
• Archived-item recovery is encoded before mutation.

Remaining Risk

This is a deterministic spec-level acceptance pass, not a live model transcript harness.

The next stronger test would be:

1. run these eight fixtures through a real skill invocation loop
2. capture the actual first reply
3. diff it against the expected section order and forbidden patterns