jiantw83andClaude Opus 5
81d02bffcf
碼錶只在領取工作包時起動，所以工時報表上規劃與分析永遠是零。久了會讓人以為 規劃不花時間，而那正是估算失準最常見的來源。 timer 加上 --stop，而且**只停 --index 指的那一顆**。每個階段停掉自己起的那一支， 錶就不會跨階段跑——跑完就去開會而錶跑一整天，報表當場失真。反過來，別顆議題上的錶 一律不碰：Gitea 在別顆議題上起新錶會靜默地停掉並記錄前一顆，那種靜默結算正是領取鎖 那條規則當初要擋的，不能在這裡反過來製造它。錶本來就沒在跑不算失敗，這一步多半排在 回報之前，報成失敗只會讓人以為前面那件事沒做成而重跑一次。 time-log 補登議題建立之前那一段——讀齊輸入、逐項詢問、組出議題內容，往往是整個 plan 最耗時的部分，而那時候議題還不存在，沒有標的可起錶。長度由腳本自己算（議題的建立時間 減掉 --since），交給 agent 做減法等於讓兩邊的時鐘各算一次，而算錯了報表上看不出來。 **不設時間上限、照實補登**：中途去開會的兩小時會一起算進去，換來這個流程不必為此 多長一題出來問使用者。 補登不是冪等的動作，所以兩種情況跳過不補：錶已經跑在這顆議題上（補登排在起錶之前， 錶在跑就代表這一段補過了），以及這顆議題上已經有工時（整個流程跑完過一次）。工時記 重複比記不到更難在報表上被發現，所以判斷偏向不補。 時間追蹤在現有環境下可能是關著的，真實路徑跑不起來；兩支都靠 --dry-run 與 stub server 測，共 27 條。 議題 #57 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
97 lines
4.2 KiB
JavaScript
97 lines
4.2 KiB
JavaScript
#!/usr/bin/env node
|
|
/**
|
|
* 起錶與停錶。
|
|
*
|
|
* 錶與領取鎖是兩件事：鎖用 assignee 加標籤（見 claim.js），錶只管工時。
|
|
*
|
|
* **領取工作包時**（sdlc-feat）兩者的時機不同：鎖要在開工之前就上好，錶則要等到
|
|
* **工作樹真的建好之後**才起。工作樹建立失敗會中止整個領取，錶要是先起了，使用者就被
|
|
* 計了一段什麼都沒做的時間，而工時要準正是工時報表的立足點。規劃與分析沒有工作樹，
|
|
* 那條規則對它們不適用——它們的標的是需求議題本身，議題存在就起得了錶。
|
|
*
|
|
* 自己的錶跑在別顆議題上時擋下，不代勞停錶：那一段時間該記在哪顆議題上只有人知道，
|
|
* 腳本自作主張會把工時記錯地方。錶已經跑在本議題上則什麼都不做——重新起錶會把已經
|
|
* 累積的時間切成兩段，而中斷後重跑正是這支腳本最常見的處境。
|
|
*
|
|
* `--stop` 停錶，而且**只停 `--index` 指的那一顆**。每個階段停掉自己起的那支錶，
|
|
* 錶就不會跨階段跑——跑完就去開會而錶跑一整天，報表當場失真。反過來，別顆議題上的錶
|
|
* 一律不碰：Gitea 在別顆議題上起新錶會靜默地停掉並記錄前一顆，那種靜默結算正是
|
|
* 領取鎖那條規則當初要擋的，這裡不能反過來製造它。
|
|
*
|
|
* 停錶時錶本來就沒在跑不算失敗：這一步多半排在別的事情做完之後（開完 PR、回報之前），
|
|
* 把「本來就沒在跑」報成失敗，只會讓人以為前面那件事沒做成而重跑一次。
|
|
*
|
|
* 用法：
|
|
* node scripts/timer.js --repo owner/name --index 40 [--stop] [--host <網址>] [--dry-run]
|
|
*/
|
|
import {
|
|
expectOk,
|
|
fetchIssue,
|
|
giteaRequest,
|
|
listStopwatches,
|
|
main,
|
|
parseFlags,
|
|
parseIndex,
|
|
parseRepo,
|
|
preflight,
|
|
resolveLogin,
|
|
stopStopwatch,
|
|
stopwatchElsewhere,
|
|
stopwatchOnIssue,
|
|
} from './lib.js';
|
|
|
|
main(async () => {
|
|
const flags = parseFlags(process.argv.slice(2), {
|
|
required: ['repo', 'index'],
|
|
optional: ['host'],
|
|
booleans: ['stop', 'dry-run'],
|
|
});
|
|
const repo = parseRepo(flags.repo);
|
|
const index = parseIndex(flags.index);
|
|
const issuePath = `/repos/${repo}/issues/${index}`;
|
|
const dryRun = flags['dry-run'] === true;
|
|
const 要停錶 = flags.stop === true;
|
|
|
|
const login = resolveLogin({ host: flags.host });
|
|
// 試跑照樣讀現況：手寫一份固定的清單會跟實作走鐘，也說不出「這顆已經在計時了」
|
|
if (!dryRun) await preflight(login, repo);
|
|
const issue = await fetchIssue(login, repo, index);
|
|
|
|
const watches = await listStopwatches(login);
|
|
const 已在計時 = stopwatchOnIssue(watches, repo, index) !== null;
|
|
// 起錶才要擋：別顆議題上的錶會讓工時記錯地方。停錶只動這一顆，擋不擋都影響不到它
|
|
if (!要停錶 && !已在計時 && watches.length > 0) throw stopwatchElsewhere(watches[0], '起錶');
|
|
|
|
// 起錶：已經在跑就不重起，重新起錶會把已經累積的時間切成兩段
|
|
// 停錶：沒在這顆上跑就沒得停，別顆議題上的錶不碰
|
|
const 動作 = 要停錶
|
|
? { 端點: 'stop', 要發請求: 已在計時 }
|
|
: { 端點: 'start', 要發請求: !已在計時 };
|
|
const planned = 動作.要發請求
|
|
? [{ method: 'POST', path: `${issuePath}/stopwatch/${動作.端點}`, body: {} }]
|
|
: [];
|
|
|
|
const 報告 = { repo, index: issue.number, title: issue.title, url: issue.html_url };
|
|
|
|
if (dryRun) {
|
|
return { dryRun: true, ...報告, requests: planned, 已在計時 };
|
|
}
|
|
|
|
if (要停錶) {
|
|
// 端點回「沒有錶在跑」的狀態碼隨站台版本而異，所以停錶走 lib 那條容錯路徑；
|
|
// 讀到的現況與實際狀態差一步（錶剛被別處停掉）也不該把整件事報成失敗
|
|
const stopped = planned.length > 0 && (await stopStopwatch(login, repo, index));
|
|
return {
|
|
...報告,
|
|
碼錶已停: stopped,
|
|
...(stopped ? {} : { note: '碼錶本來就沒在這顆議題上運轉，這一步略過；別顆議題上的錶不由這裡代停。' }),
|
|
};
|
|
}
|
|
|
|
for (const { method, path, body } of planned) {
|
|
expectOk(await giteaRequest(login, method, path, { body }), `${method} ${path}`);
|
|
}
|
|
|
|
return { ...報告, 碼錶中: true, 已在計時 };
|
|
});
|