# Agent Notification Intake - Created at: 2026-06-02 10:01 +0800 - Task id: `20260602-agent-notification-intake` - Source request: Jack asked to follow thread `019e8606-b3ae-79c2-8a8b-00df445b2e62` and make project-connected alarm notifications and online errors collectable by Agent, whether by active polling or passive system push. - Human review status: pending Jack / team review ## Repaired Question Raw request: > All systems connected to this project used to send alarms and online errors to Enterprise WeChat, or through Agent to Enterprise WeChat. Now make this project able to actively fetch those notifications, or receive notifications from systems, so the Agent captures those messages. Real job-to-be-done: > Build a unified runtime message intake layer for `zhctprompt`: every alarm, online exception, project-group feedback, SLS clue, Yunxiao/Codeup event, or WeCom robot message should enter one normalized Agent inbox, then be deduplicated, classified, enriched with evidence, and routed to Codex/people/tasks without exposing secrets or letting Agent take unsafe production actions. ## Prior Thread Reuse Thread `019e8606-b3ae-79c2-8a8b-00df445b2e62` was about the OpenAI Codex Python SDK. The reusable idea is not "chat more"; it is: - save a thread/session id, - start or resume Codex from a script, - feed logs, screenshots, messages, and repo context into Codex, - receive a structured result, - write the result back to project files or other internal tools. For alerts, this means: ```text connected systems / WeCom / SLS / Yunxiao / Codeup -> collector adapters -> normalized Agent event inbox -> dedupe + severity + routing -> Codex investigation thread or existing triage script -> evidence pack + WeCom reply draft + task index / Yunxiao follow-up ``` ## Current Project Evidence Confirmed project assets already exist: - `control/wecom-aibot/`: Enterprise WeChat intelligent robot long-connection adapter. - `work_wecom_customer_service/`: durable inbox, solution files, knowledge hits, and local case index for project-group messages. - `standards-stack/agent-skills/skills/aliyun-sls-log-triage/`: read-only SLS log triage skill and SDK query script. - `work_store/2026-05-16-qiwei-callback-alert-investigation/`: prior Enterprise WeChat callback alarm investigation. - `work/2026-06-01-server-disk-full-incident/`: production alert record for Saidi disk-full exception. Evidence level: - A: files and code inspected in this repository. - B: generated project records and thread archive outputs. - D: assumptions about future source-system webhooks or CloudMonitor setup until credentials and actual endpoints are confirmed. ## Operating Decision Use two intake modes at the same time. 1. Passive push: source systems POST alert events to an Agent notification receiver, or push to SLS/CloudMonitor/webhook that the receiver can consume. 2. Active pull: a scheduled collector reads existing sources that cannot push directly, such as WeCom robot inbox/runtime frames, SLS query windows, Yunxiao/Codeup task activity, and selected local logs. The first milestone is not automatic repair. The first milestone is reliable capture: - every event gets an `event_id`, - every event has a source and evidence pointer, - duplicates collapse into one incident, - severity and owner are suggested, - production actions require human confirmation. ## Agent-Native Contract Target workflow: - Runtime alarms, online errors, and project group feedback across smart-canteen systems. Human users: - product owner, delivery owner, backend owner, operations owner, project manager, and Jack. Agent users: - WeCom AI bot, - Codex investigation worker, - SLS triage worker, - task-index maintainer, - future Yunxiao task creator. Read actions allowed: - read sanitized WeCom message frames and inbox files, - read project docs, source index files, task index files, and existing incident records, - run read-only SLS queries through approved credentials, - read local logs and code when the workspace or Docker mount is available, - read Yunxiao/Codeup status through configured CLI/API when authorized. Write actions allowed: - append sanitized event metadata to ignored runtime JSONL files, - write AI-readable Markdown evidence under `work/` or `work_/`, - generate human review HTML, - update task-index item files, - draft WeCom replies and Yunxiao comments for human confirmation. Forbidden actions without explicit human approval: - production database writes, - refunds, subsidies, wallet/card/account balance operations, - device control, shipment, pickup, or hardware command actions, - release, rollback, merge, or deployment, - sending external customer commitments, - writing secrets, full webhook URLs, AK/SK, raw payloads, full mobile numbers, or private tokens to tracked files. ## Storage Contract Runtime sensitive feed: - `work_wecom_customer_service/runtime/notifications/*.jsonl` - `work_wecom_customer_service/runtime/incidents/*.jsonl` - These paths are covered by `.gitignore` through `work_wecom_customer_service/runtime/`. Tracked sanitized evidence: - `work//summary.md` - `work//source-index.csv` - `work//notification-source-matrix.csv` - `work//normalized-event-schema.csv` - `work//implementation-backlog.csv` - `work//.html` - `control/task-index/items/.tsv` ## First Implementation Slice P0 should be a bounded implementation in `control/wecom-aibot/`, not a broad rewrite: 1. Verify whether the Enterprise WeChat intelligent robot can receive the target alert-group messages without explicit `@arobot`. 2. Add an alert keyword route if the robot receives those messages: `报警`, `告警`, `异常`, `报错`, `exception`, `error`, `trace_id`, `No space left`, `控制器不存在`. 3. Normalize every matched message into the shared event schema. 4. Save raw-but-sanitized runtime events under ignored `work_wecom_customer_service/runtime/notifications/`. 5. For high-severity events, start or resume a Codex investigation thread using Codex CLI first, and later Codex SDK when the local SDK contract is verified. 6. Write one sanitized incident evidence pack and draft a WeCom reply. Sending can remain manual until the team accepts automatic reply rules. If the robot cannot receive passive alert messages, use one of these alternatives: - configure source systems to push to an Agent receiver and still send to WeCom, - configure SLS/CloudMonitor alert webhook to an Agent receiver, - use scheduled SLS polling and WeCom inbox polling as the first active-pull fallback. ## Why Not Create A New Skill Yet No new project skill is created in this slice. Reason: - `smart-canteen-agent-native-work-system` already covers Agent-native workflow boundaries. - `aliyun-sls-log-triage` already covers production log lookup. - `ai-native-knowledge-loop` already covers incident and launch issue knowledge回流. - `team-document-review-learning-loop` already covers Markdown plus HTML review. Create a narrow `agent-notification-intake` skill only after the first P0 collector runs on two real event types and reveals stable gotchas. Until then, a method page, schema, and implementation backlog are cheaper and less risky than adding another routing surface. ## Validation Criteria The intake layer is acceptable when: - a WeCom alert screenshot/message and an SLS online exception can both become normalized events, - duplicate events produce one incident id, - the incident has source, severity, environment, customer/project, trace id when present, and evidence path, - Codex can be launched or resumed with that event context, - the result writes a Markdown evidence pack and a short WeCom reply draft, - no secrets or raw production payloads enter tracked files, - human approval is required before production-changing actions. ## Open Questions - Which Enterprise WeChat alert groups should the robot join first? - Do those groups require explicit `@arobot`, keyword trigger, or full-message event access? - Which SLS project/logstore/region are the canonical production exception sources for `store`, `ai_api`, `food_safety`, and external customer deployments? - Should Agent auto-send low-risk "received, triaging" replies, or keep all replies manual in phase one? - Who owns severity-to-owner routing for production, customer project, development, and platform alerts?