Repository navigation
docs(work-board): record Phase 3 dogfooding evidence - #5775
Conversation
The Phase 3 start-task spike validated the capture -> revisit -> start loop on a development renderer. Record the GO decision and the verified chain, and state explicitly that it does not approve Phase 2 or Phase 4. Refs apache#2560 Generated-by: Pi (DeepSeek V4.1 Flash)
hqhq1025
left a comment
There was a problem hiding this comment.
Reviewed the current head, 5751c065. The diff changes only docs/work-board-phase1.md and docs/work-board-phase3.md; it does not change application behavior. The explicit statement that this GO does not authorize Phases 2 or 4 is useful.
[P2] Record the dogfooding evidence before treating the Phase 3 result as GO. docs/work-board-phase3.md:42-47 requires a per-run record of whether the item already existed, its resolved Host/project, first-send and restart behavior, duplicate/orphan Sessions, and manual repair. The new decision at docs/work-board-phase3.md:49-64 lists the happy-path outcome but omits the pre-existing-item/revisit observation, target identity, duplicate/orphan and repair results, and any identifiable run or test command. I also could not find a post-spike dogfooding result in the referenced #2560 discussion, where the maintainer requested that feedback be recorded. As written, a newly created item started immediately would satisfy most listed bullets without validating the stated "return to the board" assumption. Please add the run record (or link to one) with those checklist fields and the basis for the 106-test/warning claims, or narrow the GO statement to the evidence actually recorded.
The current-head hosted test and label checks, ASF header check, git diff --check, and merge-tree against current main pass. I did not independently run the development-renderer dogfooding session; CI on this docs-only head does not verify the manual observations. The AI-use statement matches the commit trailer, and I found no Grok attribution.
Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.
|
hqhq1025
left a comment
There was a problem hiding this comment.
Re-reviewed exact head cd926469. The new run record in docs/work-board-phase3.md now records whether the item pre-existed, the resolved profile/Host/project, first send, restart/reopen, link count, duplicate/orphan check, and manual repair. That addresses my previous P2 documentation gap. This is a docs-only change, and I found no product-code P0-P2 in the new diff.
[P3, disclosure accuracy] The PR's AI-use section says the commit carries a Generated-by: Pi (DeepSeek V4.1 Flash) trailer. That is true of the first commit (5751c065), but the new evidence-record commit (cd926469) has no such trailer. Please either add it to the new commit or make the statement precise about which commit carries the trailer.
The exact-head hosted test, diff-check, and merge-tree against current main pass. I did not independently observe the local dogfooding run or its SQLite data; the run record is contributor-provided evidence. This COMMENTED review is not an approval or a Phase 2/4 authorization.
Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.
liugddx
left a comment
There was a problem hiding this comment.
Reviewed exact head cd92646. Thanks @somewan820, the run record is the evidence this spike needed, and it checks out against the code.
What I verified
- The entry is gated on both
DEVand the flag (use-workbar-controller.ts:184-187), so "local development renderer" is accurate. - The
Current project/Start task/Open sessionlabels exist (conversation-copy.ts:859,879-880). - The draft is the title plus optional notes (
use-workbar-controller.ts:314). - "Open session" goes through
desktopSessionKey({hostId, sessionId})(:345-352). localand a 64-hex Host id match the profile and rootId formats.- Revision
2is exactly create + onelinkSessionwith no other edit (work-board-store.ts:146,285-294). - I also reproduced the test claim. I built the head (
apply-dependency-patches+npm run build) and ran the six listed files: 106 pass / 0 fail.
@hqhq1025's evidence P2 is addressed. I won't repeat his trailer note.
P2: the run verifies the mechanism, not the assumption the go/stop exists to test.
- What was recorded. One run, with an item that "did not pre-exist": it was created and then revisited and started in the same sitting (
work-board-phase3.md:54-56). - What the gate asks for. The gate is the Phase 1 assumption that users return to the board and start tasks from it (
work-board-phase1.md:56), which the loop is supposed to confirm through real use (:66-67). The approval's spike summary begins with an existing project item, and "whether the item existed before the action" was the first checklist field for exactly this reason. - Where the doc overclaims. "the full capture -> revisit -> start chain was verified" overstates it: the revisit happened seconds after capture. The item name
Phase 3 dogfood fixedalso suggests earlier runs. The checklist asks for every run, including failed ones and ones that needed repair. - Fix. Record this as mechanism verified; return-use not yet shown. List any earlier runs. If a full GO is wanted, add a run where the item was created at least a day before it was started from the board.
P2: the go/stop was meant to be recorded and decided on #2560, and as written this GO contradicts the approval it answers.
- Where it should live. Item 4 of the approval says "Record the results here", meaning on #2560, and asks for an explicit go/stop there. There has been no comment on #2560 since 09-04. The result exists only in the repository, as a decision declared by the spike's implementer.
- The Phase 2/4 sentence. The approval also says Phase 2 and Phase 4 "remain paused until this produces a clear go decision". The added "It is not approval to start Phase 2 or Phase 4" (
work-board-phase3.md:101-102) and the newwork-board-phase1.md:57-59together leave the GO unlocking nothing. They also add a second gate next to the existing one. - Fix. Post the run summary on #2560. I'll make the call there. My current reading is GO for the mechanism (the start-task path can move toward a non-dev entry), with Phase 2/4 still paused until return use is shown. The docs should then carry a one-line status that links that comment.
P2 (smaller): "no duplicate/orphan Session" rests on the success path, and one line reads stronger than the evidence.
- Why the link count proves nothing. Under the single-link contract,
linkSessionreplaces the array (work-board-store.ts:285-294), so "exactly onelinkedSessionsentry" holds by construction and can't show that no duplicate was created. Revision2is the actual evidence. - The known orphan path wasn't exercised. The contract documents one: restart between a failed link and the retry, which creates a second Session (
work-board-contract.md:185-191). This run didn't test it. - Fix. Say that only the success path was exercised and that the documented restart-retry limitation still stands.
P3 (non-blocking)
- Status now lives in three places and one is stale.
work-board-phase1.md:57-59,work-board-phase3.mdDecision, and the contract Status line (work-board-contract.md:22). The contract line still reads "Phase 0 … Phase 1 … shipped" and doesn't mention the merged Phase 3 spike.- Prefer a single status pointer to #2560.
docs/README.mddoesn't indexwork-board-phase3.md; that predates this PR, so it isn't yours.
- The Decision bullets repeat the run record. The machine-local Host, project and Session IDs and the test command list are evidence rather than design, and would sit better on #2560.
- "Focused Work Board tests" is looser than it reads.
task-entry-controller.test.jscontains no Work Board tests, and most ofworkbar-controller.test.jscovers other workbar tabs.- None of the six files tests the
DEVgate, so "production builds keep the entry hidden" is asserted by code review only.
- "Direct SQLite read" of the Host and Session IDs. Those values live in
record_json;workflow_work_board_itemshas no such columns (sqlite-workflow-schema.ts:119-131). This is a wording fix. - The React development-time warnings are still unnamed.
Dead ends, so nobody re-runs them: every factual claim about labels, draft contents, the link path, ID formats and the revision arithmetic matches the code. The 106 count reproduces.
Net: keep the run record (ideally on #2560), label the outcome as a mechanism-level result, let the go/stop be made on #2560, and replace the duplicated status sentences with one pointer.
hqhq1025
left a comment
There was a problem hiding this comment.
At exact head ae333ab9711571f2dbcbaf0ca3b6daaf3fbb036e, the previous evidence-record P2 and AI-trailer wording P3 are fixed. The run is now correctly scoped to a mechanism-level result, records its same-sitting limitation, preserves the restart/retry limitation, and accurately identifies which commit carries the DeepSeek trailer.
I found one remaining P2 documentation/decision-authority error: the new status links describe a contributor's request for a maintainer decision as though the maintainer decision itself were recorded there. The inline finding has the exact evidence and correction.
This head changes only three documentation files (+76/-6). The exact-head hosted test check is green; local Node 22.22.1 ASF-header and diff checks pass. Fresh main is 5735554b6fa99ab2029054c142f746c0a8fa0e71; the PR is 4 commits ahead and 11 behind, and the merge tree is conflict-free. I did not independently reproduce the development-renderer dogfooding run or inspect its SQLite database.
Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.
| # Work Board Phase 0 Contract | ||
|
|
||
| Status: Phase 0 contract shipped; Phase 1 capture/list MVP shipped in [#3135](https://github.com/apache/maka/pull/3135). Scope: `packages/core` (contract) + `packages/storage` (store and migration). | ||
| Status: Phase 0 contract shipped; Phase 1 capture/list MVP shipped in [#3135](https://github.com/apache/maka/pull/3135). The Phase 3 spike status and maintainer go/stop decision are tracked in the [Phase 3 update comment on #2560](https://github.com/apache/maka/issues/2560#issuecomment-5867638658). Scope: `packages/core` (contract) + `packages/storage` (store and migration). |
There was a problem hiding this comment.
[P2] This permalink does not contain a maintainer go/stop decision. Comment 5867638658 was posted by the PR author with contributor association; it calls the status "proposed" and explicitly asks maintainers to record the decision. There is no later comment on #2560. The same inaccurate pointer appears in work-board-phase1.md:59-60 and work-board-phase3.md:102-103. Please describe this link as the contributor's evidence/request and keep the general issue as the pending decision location, or replace it with an actual maintainer decision permalink once one exists.
hqhq1025
left a comment
There was a problem hiding this comment.
Review result for exact head b4f08a94461d23bfc20e4ed40c0d47877022e6ee: no P0-P3 findings.
The one-commit follow-up correctly resolves the previous attribution issue in all three affected documents. They now describe issue comment 5867638658 as contributor evidence and a request for a maintainer decision, while keeping the maintainer go/stop decision pending on #2560. The live issue record matches that wording: the linked comment is authored with contributor association, explicitly says that no maintainer decision is recorded there, and no later issue comment supplies one.
This remains a docs-only change (3 files, +79/-6 across the full PR). The AI-use statement matches the commit history: only the initial 5751c065 commit carries the Pi/DeepSeek trailer; the four follow-up documentation commits do not. The exact-head hosted test check passed. Locally, the ASF-header audit and git diff --check passed. Against current main 71bc045c6ddcc83f63f9228e76995527d64db5f2, the PR is 5 commits ahead and 16 behind, and merge-tree 123ddd818f1d4352c905ed841b8a784e7895ef47 is conflict-free.
I did not independently reproduce the contributor's development-renderer dogfooding or inspect the cited SQLite record. The delayed return-use case and the restart-between-failed-link-and-retry limitation remain explicitly open, and Phase 2/4 still require an actual maintainer decision.
Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.
liugddx
left a comment
There was a problem hiding this comment.
Re-reviewed exact head b4f08a9. Every point from my earlier review is addressed:
- the result is recorded as mechanism verified; delayed return-use pending;
- the run inventory is explicit;
- the Phase 2/4 wording no longer contradicts the approval;
- the link/retry wording is scoped to the success path, with the restart-retry limitation stated;
- the contract, phase1 and phase3 docs point to the same #2560 record, which is correctly described as contributor evidence;
- the test, SQLite and warning wording are corrected;
- the AI-use section now states accurately which commit carries the trailer.
Approving. I've now recorded the maintainer decision on #2560: GO for the mechanism, with Phase 2/4 still paused (#2560 comment). One small edit before merge, so the docs don't land already out of date: the three places that say the maintainer decision "remains pending on #2560" should link that decision comment and state it. They are:
- the
work-board-contract.mdStatus line; - the
work-board-phase1.mdAssumption paragraph; - the
work-board-phase3.mdDecision status section.
me2seeks
left a comment
There was a problem hiding this comment.
Automated review notice: This comment was posted by an automated review agent operated by me2seeks make. It is not an independent human review and does not replace one.
Summary
Records Phase 3 dogfooding evidence for the Work Board: the contract/phase1/phase3 docs now carry an honest run record — one 2026-09-28 run with resolved Host/project, first-send completion in ~2m35s, reopen resolving to the same Session ID with exactly one linkedSessions entry and no duplicate/orphan, no manual repair — while explicitly stating this is a MECHANISM-level result only (creation and revisit happened in one sitting, so delayed return-use is NOT yet demonstrated), that no earlier Phase 3 run exists, and that a delayed return-use run plus an explicit go/stop decision on #2560 are still required before resuming Phases 2 and 4. test lane passes.
Findings
No material findings. The record is careful NOT to overclaim: it documents the limitation (restart-before-retry can still create a second unlinked Session) and keeps Phases 2/4 paused pending the real evidence.
Verdict
merge-ready — honest, well-bounded dogfooding record with the go/stop gate preserved.
Summary
Records the mechanism-level outcome of the Work Board Phase 3 start-task
dogfooding in
docs/work-board-phase3.mdand points the Phase 1 assumption andcontract status at the contributor evidence/request on #2560. The maintainer go/stop decision remains pending on #2560.
The 2026-09-28 development-renderer run verified the project-item -> resolved
Host/project target -> normal first-send -> durable link -> restart/reopen
mechanism with
VITE_MAKA_WORK_BOARD_START_TASK=1. The item was created andrevisited in the same sitting, so the delayed return-use assumption is not yet
demonstrated. The successful link path was exercised; the documented
restart-between-failed-link-and-retry limitation remains open. Phase 2 and
Phase 4 remain paused pending the maintainer's go/stop decision on #2560.
Verification
Docs-only; no product code path changes.
git diff --checkandnpm run check:asf-headerspass. The recorded build and six-file targetedcommand pass
106/0; the manual renderer and SQLite observations arecontributor-run evidence and are not independently reproduced by CI.
AI use
Select exactly one:
Tool(s) and scope: Pi (DeepSeek V4.1 Flash) helped draft the original
dogfooding decision wording from contributor-provided evidence. Codex helped
apply the review-driven documentation changes and prepare the #2560 status
wording. The contributor verified the behavior and owns the accuracy of the
record. The initial commit (
5751c065) carries theGenerated-by: Pi (DeepSeek V4.1 Flash)trailer; the follow-up documentationcommits (
cd926469,31913b9,ae333ab, andb4f08a944) do not carry thattrailer.
Checklist
The first item does not apply to this docs-only change. No source or test files
changed.
Does this PR entail a change in behavior?
简体中文
概述
本 PR 记录 Phase 3 start-task dogfooding 的机制级结果,并将 Phase 1 假设和
contract 状态指向 #2560 上的贡献者证据/请求记录;维护者 go/stop 决策仍待在 #2560
上作出。
2026-09-28 的开发 renderer 运行验证了“项目事项 -> 解析 Host/project -> 正常首次发送
-> 持久回链 -> 重启后重新打开”的机制。但事项是在同一次操作中创建并回看的,尚未证明
隔一段时间后的 return-use;成功回链路径已验证,失败回链后重启再重试的已知限制仍然存在。
Phase 2 / Phase 4 继续暂停,等待 #2560 上的 go/stop 决策。
AI 使用
Pi (DeepSeek V4.1 Flash) 起草了最初的 dogfooding 决策措辞,Codex 协助根据 review
意见修改文档并准备 #2560 状态记录。初始 commit
5751c065带有Generated-by: Pi (DeepSeek V4.1 Flash)trailer;后续文档 commitcd926469、31913b9、ae333ab和b4f08a944没有该 trailer。