（14621期）mrc-monitor – MRC 食堂智能取餐监控助手

MRC 食堂智能取餐监控助手 基于 Firebase Firestore 的 MRC 食堂订单实时监控系统，支持多 Token 并行监控，自动推送取餐通知，解决排队等待痛点。 使用说明 核心用法 MRC Canteen Monitor 是一款专为 MRC 食堂设计的订单状态监控工具。用户只需通过简单的自然语言命令（如 "mrc 73"、"token 97" 或 "monitor 42"）即可启动监控服务。系统会自动提取消息中的所有数字 token，在后台启动 Python 监控脚本，通过轮询 Firebase Firestore 数据库（每 15 秒一次）实时跟踪订单状态。当订单状态变为 "Ready" 时，系统会立即通过 Telegram 或 Discord 发送 "🍕 Order X is ready!" 的通知。支持同时监控多个 token，且每个 token 独立通知。对于 "check" 命令，系统仅执行一次性查询而不启动后台进程。 显著优点 该技能在功能设计上展现了良好的工程实践。首先，支持多 token 并行监控，用户可一次性监控多个订单，系统会为每个 token 维护独立的监听状态。其次，采用后台进程（subprocess.Popen）运行监控逻辑，确保 Agent 能够立即响应用户而不阻塞。监控脚本具备完善的错误处理机制，包括网络超时重试（最多 5 次）、HTTP 错误处理（含 429 限流）、以及信号终止处理（SIGTERM、SIGINT），确保在各种异常情况下都能优雅退出。此外，脚本设有执行上限保护（MAX_CHECKS = 720，约 3 小时），防止无限期占用资源，并自动生成详细日志便于排查问题。 潜在缺点与局限性 尽管功能实用，但该技能存在明显的安全与架构局限。最核心的问题是第 16 行硬编码了 Firebase API Key（AIzaSyCUhOLuVBtHhhFglEYTDyp7GIIs5W2VA-Q），这构成了敏感信息泄露风险，虽然该密钥仅为只读权限且仅访问公开订单数据，但仍不符合安全最佳实践。其次，采用轮询（Polling）模式而非实时推送（Webhook），每 15 秒查询一次会造成一定的网络开销和延迟。此外，该技能与特定 Firebase 项目（kanteen-mrc-blr-24cfa）深度耦合，仅适用于 MRC 食堂系统，通用性受限。SKILL.md 文档也未明确声明所需的网络访问和子进程执行权限。 适合的目标群体 该技能主要面向 MRC（ likely a specific institution ）食堂的用餐人员，特别是那些需要同时监控多个订单（如为同事或朋友代取餐）的用户。对于希望在订单准备好后立即收到通知、避免在食堂窗口长时间排队等待的人群尤为实用。由于安全等级为 C 级且来源为 T3 级个人开发者，建议仅在个人日常使用场景中部署，不建议用于生产环境或对数据安全要求极高的企业场景。 使用风险 使用该技能需注意以下风险：首先，硬编码 API Key 虽为只读权限，但仍存在被滥用的理论可能，建议仅在可信网络环境中使用。其次，技能依赖外部 Firebase 服务的可用性，若 Firebase 服务异常或网络不稳定，监控将失效。后台脚本会持续运行最多 3 小时或 720 次轮询，期间会定期向外发送网络请求，用户需注意网络流量消耗。此外，技能通过 subprocess 调用 openclaw CLI 发送通知，这要求执行环境具备相应的 CLI 工具和权限。日志文件保存在本地 skills/mrc-monitor/logs/ 目录，需定期检查以防止磁盘空间占用。 原始说明 Real-time token monitoring for MRC canteen order system. Monitors Firebase Firestore for token status and notifies when orders are ready. Use when user sends commands like "mrc 73", "token 97", or "monitor 42" to monitor one or multiple canteen tokens. Handles multiple tokens simultaneously, sends independent notifications per token, and auto-exits when all tokens are ready.