核心用法
本技能提供了一套完整的命令行方案，通过curl直接访问Crown Town Compost客户门户（portal.crowntowncompost.com），替代需要安装的crowntowncompost-mcp服务器。核心工作流分为三步：环境变量配置（用户名/密码/端点）、Django表单登录获取sessionid Cookie、以及后续的数据查询与操作。
登录环节是本技能的技术关键——Django的CSRF防护机制要求每个POST请求必须携带三重验证：csrftoken Cookie、X-CSRFToken请求头（值与Cookie一致）、以及Origin和Referer同源头。技能文档详细给出了从登录页提取隐藏表单token、读取Cookie、构造POST的完整命令链，确保用户能一次性打通认证。
数据获取分为两类接口：两个JSON端点（服务历史/accounts/stops/api/、账单历史/accounts/billing-history/api/）支持分页、排序、过滤，返回结构化数据；其余功能（账户仪表板、环境影响数据、服务日历、预约跳过等）则通过GET请求获取服务器渲染的HTML，需配合grep/sed等工具解析。技能还涵盖了写操作（跳过服务、更新账户、提交支持请求等）的POST构造方法，并强调"302不代表成功，需回读验证"的工程实践。
显著优点
零依赖部署是最突出的优势——仅需标准curl和shell工具，无需Python运行时、Node环境或MCP服务器，特别适合容器化脚本、CI/CD流水线、边缘设备或权限受限的生产环境。
认证机制透明化将Django CSRF的复杂细节封装为可复用的csrf()函数和ctpost()/ctget()快捷命令，降低了命令行用户的认知负担，同时保留了完整的底层控制能力。
数据维度完整，覆盖了从订阅状态、历史收运记录、重量统计、账单支付到环境影响（垃圾分流磅数、种植树苗等）的全链路数据，甚至支持通过HTML解析实现"跳过服务"等交互操作，功能对等官方Web门户。
安全实践到位：密码通过stdin读取避免ps泄露、Cookie持久化到隔离文件、强调"浏览器内支付"不脚本化资金操作，体现了对凭证安全和财务风险的警觉。
潜在缺点与局限性
HTML解析脆弱性是结构性短板。服务日历、账户详情等核心功能依赖正则表达式抓取服务器渲染的HTML，一旦门户前端改版（class名、data属性变化），自动化脚本将失效，维护成本高于官方API或MCP服务器。
状态同步风险：写操作（跳过服务、更新偏好）采用"POST+回读验证"模式，但文档未提供幂等性保证或冲突解决机制，高并发或网络异常时可能出现"已发送但未确认"的模糊状态。
功能边界明确受限：明确排除支付自动化（"Pay in a browser"），且取消订阅等敏感操作需要动态读取表单字段名，难以完全自动化。此外，分页查询的perpage上限、速率限制、IP封禁策略均未文档化，大规模数据导出存在不确定性。
会话生命周期管理粗放：虽然提供了过期检测命令，但未实现自动刷新或token续期机制，长周期脚本需要自行调度重登录。
适合的目标群体
- DevOps/平台工程师：需要在监控告警、数据流水线中轻量集成堆肥服务数据，而不愿引入MCP服务器依赖的基础设施团队。
- 隐私敏感用户：不愿在本地安装额外服务或授权第三方MCP工具，偏好凭证完全由自己控制的命令行原生方案。
- 边缘/IoT场景：资源受限设备（如树莓派、OpenWrt路由器）上运行状态检查脚本，仅需
curl即可工作。 - 自动化爱好者：希望将堆肥服务数据（如下次收运日期、环境影响统计）接入个人Home Assistant、Dashboard或自托管系统的DIY用户。
使用风险
凭证泄露风险：虽然密码通过stdin输入，但export明文环境变量、Cookie文件明文存储仍存在于用户进程空间和文件系统，多用户系统或容器逃逸场景下存在暴露可能。建议配合1Password CLI等密钥管理工具（文档示例提及op read）。
服务稳定性依赖：作为非官方文档化的"逆向工程"方案，其稳定性完全取决于StopSuite平台的Django实现细节。平台更新（CSRF策略调整、端点路径变更、HTML结构调整）可能导致脚本突然失效，且无SLA保障。
数据完整性风险：HTML解析的容错性差，服务日历的跳过操作依赖特定data-*属性，若JavaScript动态渲染逻辑变更，可能产生误操作（如重复跳过或跳过失败）。
合规与审计隐患：直接操作生产账户进行自动化测试或大规模数据拉取，可能触发平台风控机制；写操作日志与用户手动操作难以区分，问题追溯时存在解释成本。