growovo 0.10.0

把重复运营工作交给 Agent，留下可核验的执行记录。
Execute authorized recurring operations with reviewable results.

简体中文 · English

Growovo 面向独立开发者与一人公司，提供 GTM/User Growth 的需求发现、价值内容、授权执行和真实结果回流。输入产品事实、目标用户与授权边界，先识别值得服务的需求，再生成可复现的价值资产和增长动作；每个动作记录成功、失败或待人工核实，不把发送、曝光或 Star 当成业务结果。

先选目标（声量 / 使用 / 商业），再选渠道（具体的地方，不是平台），然后按阶段做转化。同一个产品换目标就换打法。产品由 Demand / Execution / Learning 三层能力与 Operator Engine + Playbooks 组成：Signal Interpretation 先校验宿主语义候选，Opportunity Discovery 再判断需求与产品匹配；Value Artifact 经本地复现、授权交付和用户读回形成完整价值链，Journey 诊断真实使用断点并保留多触点非因果边界。GitHub Inbox 只是其中一个 Playbook，而不是产品总定义。CLI、MCP、Skill 共用审批、预算、回读和账本。发送成功只代表操作完成，激活、持续使用和付费分别核验。

v0.8 新增 GTM Work OS：18 个能力域、40 个岗位族和 32 个模板进入可校验注册表；不可变上下文、运营目标、WorkOrder、专业 SOP、交付物验收、跨岗位 Handoff 和 KPI 形成业务主链。work-action 只把 accepted 交付物物化为既有 plan/queue，不新增发送旁路。当前有一条完整开发者 SOP 运行链，不把注册覆盖说成 40 个专业自动化全部完成。详见实现说明。

v0.9 新增按需编排与常驻营销授权：mkt orchestrate 根据产品、目标和任务只选择必要岗位，并逐份决定交付物的内容与表达；日常发帖、回复、私信和邮件可在工作区已有明确 routine-policy 时直接执行，不再一律逐次人审。付款、合同、折扣等仍需人工，dry-run、暂停、DNC、配额、回读和未知结果保护不降级。详见编排与授权。

v0.10 新增 GTM 设计层：mkt gtm design 把增长任务拆成对象×目标×机制×渠道，先用约束（授权渠道/素材/预算/地区/数据源）筛可行性，再按目标生成结果契约与验证等级。Agent 可以提交候选机制与理由，规则只负责兼容性与边界，并保留拒绝理由；没有数据渠道时只承认平台回执，不把播放量、Star、预售订单或注册数当业务结果。详见对象×目标×机制×渠道。

先试一个结果： python3 mkt.py demo 在本地完成计划校验、审批、dry-run 和账本演示；python3 mkt.py work-demo 继续演示 WorkOrder→SOP→交付验收→交接→KPI→已审批 plan/queue，全程无需账号或网络且不执行队列。实际平台命令的验证等级见下表。能力进度与技术取舍。

为什么不自己写个脚本，或者用通用自动化平台？对比页（英文）逐项写了 Growovo 在哪输、在哪赢，并给出每条主张对应的仓库文件。

• Askovo 负责业务研究与验证，为任务提供依据。
• Growovo 执行授权运营任务，记录操作结果。
• Verovo 关联费用与业务结果，计算单任务经济性。

三者可独立使用。mkt.py 与 growovo-gtm 标识保持兼容，GTM 是首批应用场景。

合规与纪律（先读这个）

• 仅用于本人拥有或明确授权运营的账号；无授权不碰他人账号，账号归属、权限和人工接管全程留痕
• CDP 通道零凭据：不保存任何密码/token/Cookie；SMTP 凭据只走环境变量
• 一切写操作默认 dry-run，--go 才实跑；实跑须绑定已人审 plan，或显式 --routine 且工作区常驻策略覆盖该账号/渠道/动作——无授权默认拒跑，仅 CLI 人工通道 --adhoc 显式放行（账本记 adhoc=true；MCP 不开放授权管理）
• 日预算在发送前原子预留；indeterminate（未知结果）不可自动重发，必须人工 ledger resolve；contacts 的 DNC/bounced 身份与 suppress.txt 合并为同一发送抑制源
• 失败即停（不重试轰炸）；回读校验不一致绝不发送（449 空正文事故的固化）
• 人类节奏：随机间隔 + 单次硬上限 + 日预算（core/throttle.py 的表）
• 不群发：千人千面内容为前提；占位符残留会被门禁直接拒绝
• 不做对抗：不绕验证码、不伪造指纹、不用代理池绕过平台限制；代理仅可在合法网络需求明确、账号授权一致时绑定使用，且不能提高配额或绕封禁

安装与启动

先拿一个结果，再装环境。 克隆后不需要任何依赖、任何账号：

git clone https://github.com/roy-tong/Growovo.git && cd Growovo
python3 mkt.py demo               # 零网络零账号，不到 1 秒过内核四步：lint→人审→写路径→账本

要连真实渠道（X / Gmail / GitHub 写）再装运行时，并初始化工作区：

pip install -r requirements.txt   # 仅 playwright；CDP 走系统 Chrome，无需下载浏览器
python3 mkt.py init               # 建目录 + 报凭据缺口 + 打印下一步
python3 mkt.py doctor             # 环境体检（--selftest 连跑全部离线单测）
./launch.command                  # 双击亦可：首次复制登录 profile，启动 CDP 9222
python3 mkt.py check              # 确认 CDP 会话与 X/Gmail 登录态

命令矩阵与验证等级

等级含义：PROVEN=真实账号跑通；PORTED=模式已验证、本封装未整跑；UNVERIFIED=选择器未实测，首跑必须人工盯跑（首跑清单见 03 渠道文档 §5）。

规划层：计划是数据，人审是闸门（05 产品方案 §2）

# 1. 生成计划脚手架（也可直接按 data/schemas.md 手写）
mkt plan new --id askovo-p0 --goal '拿到 20 个激活' --beachhead '独立 UX 研究者' \
  --hypothesis '证据分级是购买动机' --channel email --wave-action message --size 10

# 2. 校验（schema/能力矩阵/size≤内核日预算）
mkt plan lint --id askovo-p0

# 3. 人审：必须署名；写审批事件 + 计划指纹（批准后再改计划会被指纹识别并拒跑）
mkt plan approve askovo-p0 --by roy --days 7

# 4. 队列：模板 + 目标 CSV 生成，或手写后用 lint 过门禁
mkt queue build --campaign askovo-p0-w1 --channel email --wave-action message \
  --template assets/outreach.md --targets data/targets.csv
mkt queue lint data/queues/askovo-p0-w1.json

# 5. 人审预览 → 干跑 → 实跑
mkt review askovo-p0-w1
mkt email message --queue data/queues/askovo-p0-w1.json          # dry-run
mkt email message --queue data/queues/askovo-p0-w1.json --go     # 须已批准

# 6. 记账与复盘
mkt link create --campaign askovo-p0-w1 --channel hn --url https://example.com
mkt outcome import data/events.csv --campaign askovo-p0-w1
mkt outcome sync --campaign askovo-p0-w1
mkt campaign report askovo-p0-w1

计划指纹 = 计划内容（不含 review 块）的规范化 sha256；旧计划只有 human_approved=true 时仍按 legacy 放行，新审批一律带指纹与有效期。

上限是内核属性：计划里的 size 超过 core/throttle.py 日预算会被 lint 拒收。

MCP 服务（mcp_server.py，stdio，零依赖）

{"mkt": {"command": "python3", "args": ["/绝对路径/Growovo/mcp_server.py"]}}

10 个工具，全渠道读写：

• 读：mkt_status / mkt_channels / mkt_plan_lint / mkt_search（x/reddit/linkedin/hn/github）/ mkt_ledger_query / mkt_campaign / mkt_inbox（hn/github/email/x）/ mkt_audit（github）
• 写：mkt_run_queue（全渠道队列，默认 dry-run）/ mkt_action（单条动作，同一套门禁/审批/账本）

写操作实跑一律要求已人审 plan；UNVERIFIED 渠道需 allow_unverified=true（人工首跑校准）；adhoc 仅 CLI 人工通道，MCP 不开放。MCP 进程同样读 MKT_HOME，可与 CLI 用不同工作区。

Skill（skills/）

• skills/growovo-gtm/SKILL.md：GTM 操作协议——入口是增长目标（注册/激活/付费）而非单个渠道动作，按四引擎（定位→资产→投放→结果）拆解为七步：目标→plan→客群→人审→执行→复盘。装入 ~/.agents/skills/ 即可在 ZCode 等宿主触发（内容协作走 warm-email-outreach / expert-review-outreach / b2b-account-mapping）。
• skills/github-project-ops/：GitHub 项目经营协议（开源与闭源通用）——定位诊断（四象限+七阶段）→ 仓库体检清单 → 增长 playbook → 闭源经营模式库；含独立体检脚本 scripts/repo_audit.py（零依赖发行版）。与 CLI 的关系：skill 是协议与判断，mkt github * 是采数与执行。

案例（docs/cases/）

第一波案例来自 ovo 家族自身，每个案例都区分「平台动作」与「业务结果」，不为获客改写状态：

• Askovo：首位 dogfood 客户——operator 275 分钟 / human 5 分钟跑完定造跑；2026-11-03 起不设判决日，按迭代节奏推进
• Verovo：前置案例——一轮完整 GTM 的代价→默认值映射；Growovo 每条纪律都有出处
• Growovo：自举——改名、双语 README、dogfood 回路，每次自我运营走自己的管道

通道层（core/transports.py）

ACTIVE×4：api（OAuth，Reddit 二期）｜browser-cdp（PROVEN）｜os-input（macOS 键鼠/AX 模拟，UNVERIFIED，transports/os_input.py）｜protocol（SMTP/IMAP，PROVEN）。 RESERVE×6（通道储备库）：webdriver｜rss-public（只读）｜esp-api（事务邮件）｜mobile-appium｜integration（平台原生）｜semi-auto-ui（人工确认兜底）。 每渠道×动作声明首选+降级链；降级用于"路不通"，不用于"绕风控"——风控信号的响应是降节奏或 mkt pause，不是换马甲。风控阈值与账号限额见项目 06 文档（官方口径亲核；代码预算一律低于官方上限，见 throttle.INTERVALS/OFFICIAL_LIMITS）。

环境变量

数据三件套（data/，gitignore）

• queues/<campaign>.json 队列；ledger.jsonl 全局账本；contacts.jsonl 线索库
• suppress.txt 抑制名单（每行一个目标）；shots/ 留证；state/ 日预算状态
• schema 详见 data/schemas.md

结构

core/      ledger 账本（含人工裁决覆盖）· gates 门禁（含 DNC 合并）· throttle 原子日预算 · pipeline 写路径事务 · evidence 留证 · cdp 会话 · transports 通道注册表 · planlint 计划校验 · approval 执行级审批（计划+队列+账号+工作区指纹）· queue 编辑期门禁 · campaign 视图/人审预览/下一步 · followups 跟进台账 · intent 可配置学习实验 · logscan 日志扫描 · retro 渠道账/冲突/规则 · narrative 四件套叙述 · platforms 平台单一数据源（37 个）· voice 平台语气画像（37 个）· experience 五类经验资格（当前 129 条原始记录，不自动合资格）· strategy 主渠道/冷启动/放大 · cadence 四周动作表 · execute 策略→计划队列 · result 同范围三层结果 · revise 参数回流 · progress 日报周报 · signal_interpretation 语义候选校验 · opportunity 需求发现 · value_artifact 价值资产 · value_delivery 价值交付状态机 · journey 时序/身份/多触点旅程 · playbook_model 三维组合 · accounts 授权账号生命周期 · network 代理引用 · billing 报价实验 · links 追踪链接 · outcome_io CSV 导入与账本聚合 · collector 本地 webhook/跳转 · action_runner 单条动作 · queue_runner 全渠道队列 · playbooks GitHub Inbox 分流/草稿队列 · workflows 配方学习/审批/重放 · locators 定位器阶梯 · scorecard 记分卡 · optimization 优化建议 · scheduler 持久化排期 · workspace 多产品隔离 · experiments 可选学习实验 · attribution 事件/漏斗/归因 · demo 零账号演示 · doctor 环境体检
channels/  x/(vendor+adapter) · email_smtp · email_cdp · reddit · linkedin · github（api 通道首发） · hn（CDP 写 + Algolia 读）
transports/  os_input（macOS 键鼠/AX 模拟，UNVERIFIED）
skills/    growovo-gtm（GTM 操作协议）· github-project-ops（GitHub 项目经营协议+体检脚本）
tests/     离线单测（599 项，含 449 事故回归、全渠道人审门禁/adhoc 放行、执行级审批指纹/队列篡改/账号与工作区绑定、预算原子预留、DNC/indeterminate 阻断、真实 CLI 端到端、37 平台策略/节奏/人工单契约、语义对抗/真实复现交付链/时序身份多触点旅程/经验可追溯复核、账号与报价实验、demo 闭环与 doctor 分级）：python3 -m unittest discover -s tests
mcp_server.py  MCP 外壳（stdio JSON-RPC，零依赖）

X 渠道 vendor 引入 x-ops-automation（上游 github: roy-tong/x-ops-automation）， 不改写已验证代码（见 channels/x/vendor/PROVENANCE.md）；上游修选择器时同步。

License

MIT（见 LICENSE）。channels/x/vendor/ 引入自同作者仓库 x-ops-automation（MIT）。

可复用工作流：一次学习，稳定重放

同一类操作不必每次让模型重新探索页面。workflow 把步骤、定位器阶梯与回读条件固化成带指纹的配方；批准后才可 --go，每次运行都有逐步日志：

python3 mkt.py workflow learn hn-reply --trace trace.json      # 观察一次 → 草稿（不自动批准）
python3 mkt.py workflow approve hn-reply --by "operator" --days 30
python3 mkt.py workflow replay hn-reply --var item=123 --var text="…"          # dry-run：只解析定位器
python3 mkt.py workflow replay hn-reply --cdp-url http://127.0.0.1:9222 … --go  # 实跑
python3 mkt.py workflow runs
python3 mkt.py workflow reconcile --run <id> --outcome not_sent --note "已核对平台后台" --by "operator"

页面变化时按 css → placeholder → label → role → text 逐级恢复；视觉恢复需要操作者提供 provider，没有就停在 visual_unavailable，不猜点击位置。写入仍走统一门禁：action 步骤复用 action_runner，commit 点击检查暂停与日预算并写账本。详见工作流。

运营记分卡、排期与优化建议

执行之后要看得见结果，也要能停下来。scorecard 把账本与业务事件分开统计：确认率、未知率、失败数与证据覆盖率，不把「发出去了」算成转化。

python3 mkt.py scorecard --campaign my-campaign
python3 mkt.py optimize --campaign my-campaign          # 人工决策建议，不自动执行
python3 mkt.py schedule add --id daily --queue data/queues/q1.json --interval 1440
python3 mkt.py schedule tick                            # 由 cron/launchd 或人手动触发
python3 mkt.py schedule resume --id daily --note "已核对未知回执"

• 排期只跑「到点的一波」；全局暂停、未知结果、失败队列都会让它停下并标 needs_review；
• 进程中断后的 running 波次不会被自动重跑；
• optimize 的比较是描述性的：高确认率不等于渠道效果，建议全部 requires_human: true。

运营记忆：从已核验的平台回执中学习

在不暴露联系人明细、也不自动重放任何历史动作的前提下，检视重复出现的渠道/动作模式：

python3 mkt.py memory --campaign my-campaign
python3 mkt.py memory --channel github --output data/operations-memory.json

摘要报告已确认的平台操作、未知/失败回执与人审候选；有意排除目标对象与消息正文。平台动作成功不等于客户激活，模式也永远不是重放许可：新的执行仍需新的授权、当期平台政策检查与标准执行门禁。这是工作流学习的只读输入：它给出模式与风险，真正可重放的配方在批准后由 mkt workflow 执行。见能力进度与技术取舍。

参与

• 改动前先读 CONTRIBUTING.md：里面是不能破坏的执行不变量（人审、dry-run、暂停、预算、抑制名单、回读校验、未知结果不重试）与 AI 贡献政策。
• 安全问题走 SECURITY.md 的私密通道，不要开公开 issue。
• issue/PR 首次响应目标 48 小时内；能力边界与验证等级以 docs/feature-status.md 为准。
• 案例（含失败与判死）在 docs/cases/，不删改状态。