LifeOS Work System以 GitHub Issues 为唯一事实源的工作捕获、周期清扫与看板渲染体系【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS本篇基于 LifeOS 仓库中 WorkSystem.md 设计文档展开完整讲解 LifeOS Work System 的核心机制如何把每一段有意义的工作ALGORITHM/NATIVE 会话、显式提醒、停滞项目检查、无落地的 TELOS 目标统一捕获为带标签的 GitHub Issue再经 Pulse Work 看板、自动再生的 TASKLIST.md 与 Agent 认领流程多路消费。读完本文你可以掌握 Work System 的捕获—事实源—渲染三层架构、单一配置加载器的隐私契约、WorkSweep 周期清扫的实现细节与全部可调参数并能在自己的安装中完成 repo 绑定、标签播种与调度注册的全套配置。设计动机与总体架构Work System 的定位是 LifeOS 爬升循环hill-climb的账本每个被捕获的工作单元都是向理想状态迈出的一个步骤而周期性清扫TELOS sweep是闭环的最后一段——一个活跃目标却没有对应 open issue正是系统应该暴露出来的缺口。重构前的失败背景值得记录在 2026-05-25 重构之前一个月的数百个会话中只有 1 个落入了工作仓库捕获率不足 1%。三个独立缺陷叠加所致(a) SessionEnd hook 跳过了 NATIVE 模式会话而当前大多数 prompt 都被归类为 NATIVE(b) hook 写入的Type:*/Status:*前缀标签在仓库中不存在导致 issue 裸落无标签(c) 手工维护的 TASKLIST.md 五周未更新。捕获近乎为零、渲染错误、统一视图陈旧——重构同时闭合了这三个环并新增了第四个捕获面周期清扫专门接住事件驱动 hook 会漏掉的不作为。整体数据流如下原文档架构图所有捕获面与渲染面都通过hooks/lib/work-config.ts从同一棵USER/WORK/配置树读取WORK.REPO、看板列与 project→property 映射。SYSTEM 代码中不存在任何 principal 特有标识——换一个work_repo.json指向另一个私有仓库整套系统即完成切换。单一配置源与隐私契约配置加载器 work-config.ts 是整条链路的地基。它定义了明确的隐私契约privacy contract核心规则在源码注释中逐条列出状态行为work_repo.json不存在disabledreasonmissing这是 setup 前的正常状态不是打包缺陷JSON 中verified_privatefalsedisabledreasonnot_privateverified_at超过半 TTL默认 12h加载器调用gh repo view repo --json visibility,isPrivate重新验证成功则回写新的verified_at原子写入权限 0600gh 失败但缓存未超全 TTL 则带备注继续grace 期超过全 TTL 则 disabledreasonstale_unverifiedrepo 翻转为 public无论 TTL 一律 fail closed加载器从不信任手工编辑的verified_private声明SetWorkRepo工具是唯一受认可的写入路径。work_repo.json的结构在源码中定义为{ repo: owner/repo, privacy: { verified_private: true, verified_at: 2026-06-13T00:00:00Z, visibility: PRIVATE, ttl_hours: 24 } }repo 名称受正则^[A-Za-z0-9._-]\/[A-Za-z0-9._-]$校验见 work-config.ts 的REPO_REGEX。config.yaml承载 UX 默认值加载器对其解析全部走内置的轻量 YAML 切片函数sliceBlock/extractScalar/extractList零依赖、零抛错——任何配置损坏都降级为 disabled 状态而非崩溃。默认值在源码中明确DEFAULT_COLUMNS [Queued, Blocked, In-Progress, In-Review, Complete]work-config.ts#L54DEFAULT_POLL_SECONDS 60work-config.ts#L55CAPTURE_NATIVE/CAPTURE_SWEEP默认均为true接受true/yes/1与false/no/0三种写法WORK.PROJECT_PROPERTY解析为 project→Property:*的嵌套映射块未命中时回退Property:internalWORK.AGENT_LABEL配置Agent:name标签默认Agent:principal保证任何人名不出现在公开代码里值得注意的工程细节三个消费方WorkSweep.ts、work-config.ts、work.ts顶部都有同一段环境变量归一化代码把 Claude Code 注入的未展开的$HOME/${HOME}字面量替换为真实主目录避免路径解析到影子目录注释中引用了 issue #1404 / PR #1451。四个捕获面按优先级1. SessionEnd hook ——ULWorkSync.hook.ts私有组件这是一个私有组件不在公开发布载荷中。hooks/ULWorkSync.hook.ts与 work-tracking skill 都指向 principal 的私有工作仓库像所有下划线前缀的私有 skill 一样被 rsync 从公开发版中排除。该捕获面仅在 principal 自己的安装上运行全新公开安装不含此组件在公开仓库中确实检索不到该文件与文档描述一致。它在每次会话结束时触发用会话 UUID 查MEMORY/STATE/work.json、定位 ISA、决定同步与否。同步门控sync gatesWORK.REPO已启用且验证为私有否则静默 exit 0ALGORITHM 会话phase ∈ {execute, verify, learn, complete}NATIVE 会话CAPTURE_NATIVE: true且会话目录内除ISA.md外至少有 1 个产物输出行为按 slug 键控幂等地创建或更新单个 issue标题前缀[LifeOS]ALGORITHM或[Native]NATIVE标签组合pai-syncType:feature或 native 的auto-nativeType:queue 来自 project 映射的Property:* 来自 phase 的Status:* 来自 effort 的Priority:*Agent:da-name标签先用仓库实际存在的标签集预过滤不存在裸 issue 兜底把github_issue与github_issue_url写回 ISA frontmatter永远 exit 0绝不阻塞phase: complete2. UserPromptSubmit hook ——ReminderRouter.hook.ts该 hook 在每次 prompt 提交时触发用一组**精度优先precision over recall**的正则匹配remind me to X、research the Y、queue this for Z later等显式指令命中即创建带标签的 issue。ReminderRouter.hook.ts 中定义了完整触发器表全部要求在行边界prompt 开头或换行后匹配绝不做句中匹配类型触发句式节选reminderremind me to/about ...、set a reminder to/for/about ...、add a reminder to ...、remember to ...researchresearch the ...、research this, ...、we should research ...queuequeue this/that for/as ...、add this/that to my/the queue/todo/backlog、we should do ... later.实现要点均可在源码中验证会话内幂等prompt 做 SHA1 取前 16 位哈希记录在MEMORY/STATE/reminder-router-seen.jsonReminderRouter.hook.ts#L128-L153每个 session 最多保留 64 条相对日期解析内置一个极简解析器识别today、tomorrow、in N days/weeks、next weekday、裸星期名转成 ISO 日期写入 issue body 的Due:字段fire-and-forget 建 issuegh issue create以 detached 方式 spawn不等待退出绝不阻塞 prompt 路径ReminderRouter.hook.ts#L192-L201未命中的 prompt 只付出一次正则测试即退出公共路径无可感知延迟WORK.REPO未配置时静默跳过建出的 issue 标题带[Reminder]/[Research]/[Queue]前缀body 原样保留触发词、类型、Due 日期与完整原始 prompt标签固定为Type:kindProperty:internalStatus:queuedPriority:P3Agent:namepai-sync见 buildIssue。软性暗示soft hints被刻意不匹配——精度优先于召回想被捕获时显式用触发句式即可。3. 周期清扫 ——WorkSweep.ts 60 分钟调度这是重构新增的关键捕获面。WorkSweep.ts 由~/Library/LaunchAgents/com.lifeos.worksweep.plist每 60 分钟触发一次也可手动运行bun ~/.claude/LIFEOS/TOOLS/WorkSweep.ts # apply bun ~/.claude/LIFEOS/TOOLS/WorkSweep.ts --dry-run # 只看会做什么 bun ~/.claude/LIFEOS/TOOLS/WorkSweep.ts --since 48h # 扩大扫描窗口四个子清扫sub-sweep子清扫触发条件输出Session catch-up24h 内修改过、无github_issue:回写、仓库中无 slug 匹配的现有 issue、达到有意义工作阈值的 ISA[Sweep]或[Native]issue带auto-sweep/auto-native来源标签Stale flagging带Status:in-progress且 7 天无更新的 open issue追加stale标签Project checkPROJECTS.md中被跟踪的项目 14 天无提交、当前无 open issue[Project-Check]issue含项目名与天数Goal derivationPRINCIPAL_TELOS.md中活跃 TELOS 目标G 前缀匹配零个 open issue[Goal]issue含目标文本与 ID 锚点源码中还能看到文档表格之外的实现细节有意义工作阈值isMeaningfulWorkALGORITHM 会话必须已通过ascent.ts的phaseHasWorkStarted判定历史上本地硬编码的 phase 列表曾停留在已退役的 8 站词汇表导致climbing阶段被误判为放弃的脚手架而永不建 issueNATIVE 会话要求目录内除ISA.md外至少 2 个产物WorkSweep.ts#L112-L130Type 自动分类classifyType用关键词把任务文本分入Type:problem/research/decision/reminder/project/feature真正无法归类的才落回Type:queue让工作列表可按类型过滤WorkSweep.ts#L217-L232Project-Check 去重前缀按稳定的[project-check] name —前缀匹配而非完整标题因为标题中的天数每天变化精确标题匹配会导致每天重复建单源码注释称之为12-13 倍重复 bug从源码结构看main() 实际还编排了第五个子清扫sweepBpeCadenceBPEBitterPillEngineering减法审计以 30 天节奏到期时建一条[BPE]propose-only 提醒 issue可用--stamp-bpe重置时钟——这属于文档四个子清扫表述之外的实现增量全程无 LLM只有gh 文件系统读取约 15–20 秒跑完任何gh失败只记日志、始终 exit 0每轮向MEMORY/OBSERVABILITY/worksweep.jsonl追加一行 JSON 统计sessions_scanned、issues_created、issues_stale_labeled、project_checks_created、goal_issues_created、duration_ms、errors等字段安全护栏--max-create N默认 50限制单轮建单数量避免首次安装的失控洪泛--dry-run只展示不落库空脚手架无进度、无阶段推进按阈值跳过早于--since窗口默认 24h的会话跳过除非显式放宽不做追溯性洪泛四个子清扫结束后WorkSweep 调用RegenerateTasklist.ts --commit-push保证 TASKLIST.md 常新。源码中该步骤是探测后再 spawnRegenerateTasklist 属于私有 work-tracking skill公开安装中路径可能不存在无条件 spawn 会让每次清扫尾部都打印一条 module not found——所以先用existsSync检查再生成。调度注册由 InstallWorkSweep.ts 完成且比文档所述更进一步它按process.platform双后端安装——darwin 走 launchd把{{HOME}}/{{BUN}}/{{BUN_DIR}}占位符替换进 com.lifeos.worksweep.plist.template 后launchctl bootstraplinux 则生成 systemd user service timer 并用systemctl --user启用需loginctl enable-linger才能注销后存活。支持--uninstall与--status安装幂等先拆旧单元再装新的。plist 模板的关键参数StartInterval 360060 分钟、RunAtLoad true登录即跑一次、ThrottleInterval 60崩溃循环限速、stdout/stderr 均落到MEMORY/STATE/com.lifeos.worksweep.log。4. 手动 —— work-tracking skill / gh CLIwork-tracking skill 的 CheckTasks、AddReminder、CreateIssue、UpdateTaskList 工作流加上直接调gh。没有任何自动化——由 principal 或 Agent 直接操作。标签体系与标题前缀规范标签清单在USER/WORK/labels.yml由 work-tracking skill 的BootstrapLabels工具推送到配置仓库纯增量——从不删除已有标签家族成员用途Type:feature, problem, reminder, research, queue, decision, metric-alert, project什么类型的工作Status:queued, needs-triage, ready, in-progress, in-review, blocked, needs-human, done处于什么状态Priority:P0, P1, P2, P3多紧急Property:newsletter, website, youtube, podcast, community, consulting, open-source, internal, pai, life属于人生的哪个领域Agent:用户机队中每个 principal 命名的 agent 一个principal 自行编辑labels.yml添加自己的名字谁负责Flagspai-sync、auto-native、auto-sweep、da-name-can-takeDA 名字作为前缀、stale正交的来源/队列标记遗留裸标签feature、P2-medium、internal、in-progress等与新标签共存Pulse 模块通过LEGACY_STATUS_ALIASES把它们别名到规范的 Status 值让新旧 issue 渲染在同一列中。该别名表在 work.ts#L98-L113 中定义例如inbox/ready/triaged/queued/needs-triage → Queued、in-progress/ai-working → In-Progress、needs-human → In-Review、done/complete → Complete未带Status:前缀的裸标签同样被识别。标题前缀是 issue 来源的第一个信号被RegenerateTasklist.ts与看板的 source badge 共同使用前缀来源时机[LifeOS]SessionEnd hookphase ≥ execute 的 ALGORITHM 会话[Native]SessionEnd hook扩展或 sweep有文件产物的 NATIVE 会话[Reminder]ReminderRouterprompt 匹配remind me to X[Research]ReminderRouterprompt 匹配research the Y[Queue]ReminderRouterprompt 匹配queue this for Z later[Sweep]周期清扫补捞的未跟踪 Algorithm 会话[Project-Check]周期清扫被暴露的停滞项目[Goal]周期清扫无 open issue 的活跃 TELOS 目标渲染层Pulse Work 标签页、TASKLIST.md 与 Agent 认领Pulse Work 模块 ——LIFEOS/PULSE/modules/work.tswork.ts 每WORK.POLL_INTERVAL_SECONDS默认 60s轮询一次gh issue list --state all --limit 500 --json ...把 issue 按Status:*标签含遗留别名分组到WORK.KANBAN_COLUMNS配置的泳道对外提供GET /api/work— 完整载荷config、columns、items、lastFetch、staleGET /api/work/columns— 仅按列分组结果GET /api/work/status— 模块健康状态enabled、repo、last_fetch、poll 间隔、缓存路径GET /api/work/ui— 看板 HTMLPOST /api/work/refresh— 强制立即轮询该模块严格只读从不改仓库。每张卡片带来源徽章pai-sync/auto-native/auto-sweep/reminder/bookmark/manual由 issueSource 依标签推导让人一眼看出 issue 从哪个捕获面进来。健壮性设计在源码中清晰可查列推导CLOSED 的 issue 强制进Complete/Done/末列open issue 无Status:*标签时落Queued回退Inbox再回退首列stale 缓存降级gh离线或未认证时返回上一次成功快照并置stale: true判定阈值为缓存年龄超过 2.5 倍轮询间隔Pulse UI 顶部展示横幅未配置时返回 setup 模板而非报错/api/work返回setup_required: true加四条具体指令写work_repo.json的完整 JSON 样例、需要预置的标签清单、重启 Pulse、跑一次 Algorithm 会话并把 WorkSystem.md 作为 docs 指引stderr 并发排空gh调用同时读 stdout 与 stderr避免 gh 输出撑满管道缓冲导致 12s 超时假死注释中引用 issue #1482 的修复背景卡片还能展示本地 ISA frontmatter 中的principal_stated_goal标题中[slug:xxx]解析出 slug 后回读MEMORY/WORK/{slug}/ISA.mdTASKLIST.md —— 自动再生由 work-tracking skill 的RegenerateTasklist工具拉取全部 issue按标准分区Active / Queued / Triaged / Projects / Reminders / Blocked / Recently Completed重写文件可选 commit push。幂等——空 diff 不产生 commit。WorkSweep 以--commit-push调用它使 live 仓库永远反映真实状态。Agent 认领流程目前完全手动gh issue edit num --repo $REPO --add-label Agent:agent-name,Status:in-progress --remove-label Status:ready,Status:queued # ...工作... gh issue close num --repo $REPO --comment Resolved: evidenceda-name-can-take标签充当该 DA 应接手此项的队列标记。目前是手动的未来的自主认领守护进程独立 ISA已延后会扫描该标签并派发到 ALGORITHM 会话。系统 / 数据 / 模板三层分离层位置内容是否随发布分发系统代码公开~/.claude/LIFEOS/PULSE/、~/.claude/LIFEOS/TOOLS/、~/.claude/hooks/下的通用捕获 hook模块、CLI、通用 hook是——脱敏、公开安全私有组件work-tracking skill 目录、~/.claude/hooks/ULWorkSync.hook.ts下划线私有 skill 指向 principal 私有工作仓库的 SessionEnd 捕获 hook否——从公开发版载荷中 rsync 排除用户配置~/.claude/LIFEOS/USER/WORK/labels.yml、config.yaml、work_repo.json、README.md否——由 work-system setup 创建不分发。这些是 USER 区文件受 containment 策略排除全新安装没有USER/WORK/直到 setup 写入因此该目录缺失是 setup 前状态而非打包 bug当前公开仓库中确实不存在此目录与描述一致新用户模板仅维护者侧位于 release skill 的RELEASE_TEMPLATES/WORK_REPO/——尚未进入发布载荷README 模板、TASKLIST 起始文件、.github/labels.yml、ISSUE_TEMPLATE、workflows尚未——用户 setup 时的占位符替换是计划中的未实现live 仓库配置的私有 GitHub 仓库Issues、TASKLIST.md、README、SOPs、CHANGELOG否——用户私有财产新用户跑 work-tracking skill 的SetWorkRepo --bootstrap owner/repo工具计划中后验证仓库私有、写入 privacy-attested 的work_repo.json、跑 BootstrapLabels 播种标签体系、把模板克隆进新仓库并做占位符替换、commit push。此后整套系统零代码改动地指向他们的仓库。失败模式与恢复模式行为恢复gh离线/未认证hook exit 0sweep exit 0Pulse 带stale: true横幅返回缓存重跑gh auth login下次轮询/清扫自动恢复仓库翻转为 publicwork-config.ts重新验证在半 TTL12h内捕获禁用同步改回 private或用 SetWorkRepo 指向新私有仓库仓库缺少标签hook 把标签过滤到已存在的记录缺失名sweep 同理bun BootstrapLabels.ts播种slug 冲突两个 ISA 同 slugissue 标题查找上后写胜出两者更新同一 issue重命名其中一个 ISA 的 slugsweep 崩溃launchdThrottleInterval: 60限速结构化错误追加到 worksweep.jsonl读MEMORY/STATE/com.lifeos.worksweep.logTASKLIST 再生器无法 push本地文件仍更新记录push failed (auth/network/conflict)下次运行重试解决本地 clone 的 git 状态首次安装的大回填洪泛--max-create 50默认上限分批 triage用--since 720h --max-create 50反复跑直到追平新用户 Setup 步骤创建一个私有 GitHub 仓库运行 work-tracking skill 的SetWorkRepo --bootstrap owner/repo工具计划中——目前手动完成第 3–5 步运行BootstrapLabels --repo owner/repo工具播种标签体系重启 Pulsebash ~/.claude/LIFEOS/PULSE/manage.sh restartbun ~/.claude/LIFEOS/TOOLS/InstallWorkSweep.ts注册调度任务darwin 上为 launchdlinux 上为 systemd user timer跑任意 Algorithm 会话——ULWorkSync.hook.ts在 SessionEnd 打开第一个 issuesweep 在一小时内接住其余全部可调参数速查设置位置默认值用途WORK.REPOwork_repo.json无——必填目标仓库必须私有WORK.KANBAN_COLUMNSconfig.yamlQueued, Blocked, In-Progress, In-Review, CompletePulse 看板泳道WORK.POLL_INTERVAL_SECONDSconfig.yaml60最小 10Pulse 轮询节奏WORK.CAPTURE_NATIVEconfig.yamltrueSessionEnd hook 中开启 NATIVE 捕获WORK.CAPTURE_SWEEPconfig.yamltrue开启周期清扫WORK.PROJECT_PROPERTYconfig.yamlproject→Property 映射把 ISA 的project:值映射到Property:*标签Sweep--max-create NCLI 参数50单轮清扫建单上限Sweep--since NhCLI 参数24会话补捞的扫描窗口小时LaunchdStartIntervalplist3600清扫节奏秒另有两个源码级参数未出现在文档表格中--stamp-bpe重置 BPE 减法审计时钟BPE 节奏由常量BPE_CADENCE_DAYS 30控制WorkSweep.ts#L62。关键文件清单文件角色USER/WORK/labels.yml规范标签源用户区setup 时生成USER/WORK/config.yaml看板列 轮询节奏 捕获开关 project→property 映射USER/WORK/work_repo.json仓库身份 隐私证明USER/WORK/CLAUDE.mdCustomers/子树的 RESTRICTED 分类hooks/ULWorkSync.hook.tsSessionEnd 捕获ALGORITHM 有产物的 NATIVE私有不在公开仓库中hooks/ReminderRouter.hook.tsUserPromptSubmit 捕获显式触发hooks/lib/work-config.ts仓库、列、开关、project 映射的单一加载器LIFEOS/TOOLS/WorkSweep.ts周期清扫——子清扫 TASKLIST 再生LIFEOS/TOOLS/com.lifeos.worksweep.plist.templatelaunchd plist 模板LIFEOS/TOOLS/InstallWorkSweep.ts实例化模板、bootstrap 调度任务launchd / systemd 双后端LIFEOS/PULSE/modules/work.ts带来源徽章的 Pulse 看板渲染器work-tracking skillBootstrapLabels工具把规范标签播种进配置仓库work-tracking skillRegenerateTasklist工具从 live issues 重建 TASKLIST.mdwork-tracking skillSetWorkRepo工具仓库身份 setup已存在——--bootstrap扩展计划中MEMORY/OBSERVABILITY/worksweep.jsonl每轮 sweep 一行 JSONMEMORY/STATE/com.lifeos.worksweep.loglaunchd 的 stdout/stderr 捕获端到端示例一句话的完整旅程会话中途有人输入remind me to renew the TLS cert next week.这句话不会作为松散任务到达任何 agent——它在门口被截住。ReminderRouter.hook.ts在 prompt 上触发匹配remind me to X形状并按相对日期解析器从 next week 提取到期日在 work 仓库开出一个带标签的 issue标题前缀[Reminder]打上Type:reminder与Status:queued泳道标签。一个轮询周期内它成为 Pulse Work 标签页上的一张卡片下一次 TASKLIST 再生把它写进文件。一句话零仪式进入事实源。而 sweep 捕获的是事件漏掉的不作为事件 hook 只在有事发生时触发留下的缺口是应该存在却不存在的 work。每 60 分钟它读一次 TELOS 目标为任何匹配 open issue 数为零的活跃目标开[Goal]issue。一个已表述的理想状态却没有下一步动作正是 OS 应该暴露的东西——没有任何 hook 能触发这件事因为根本没有输入发生而 sweep 就是那个自我闭合的环。整套设计的精髓在于捕获与渲染通过单一事实源解耦——hook 永远只写 issue看板、任务列表、Agent 认领流程都是这一个源的下游读者。相关文档ISA 规范ISAFormat.md系统/用户边界准则SystemUserBoundary.mdContainment 策略Containment.mdPulse 系统PulseSystem.mdWork System 原文档WorkSystem.md【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考