docs: prune completed experiment plan notes

This commit is contained in:
Peter Steinberger
2026-02-22 21:56:01 +01:00
parent 382785c6ce
commit 3a088c9f4f
4 changed files with 4 additions and 114 deletions

View File

@@ -528,12 +528,12 @@
"destination": "/channels/pairing"
},
{
"source": "/plans/cron-add-hardening",
"destination": "/experiments/plans/cron-add-hardening"
"source": "/experiments/plans/cron-add-hardening",
"destination": "/automation/cron-jobs"
},
{
"source": "/plans/group-policy-hardening",
"destination": "/experiments/plans/group-policy-hardening"
"source": "/experiments/plans/group-policy-hardening",
"destination": "/channels/groups"
},
{
"source": "/poll",
@@ -1281,8 +1281,6 @@
"group": "Experiments",
"pages": [
"experiments/onboarding-config-protocol",
"experiments/plans/cron-add-hardening",
"experiments/plans/group-policy-hardening",
"experiments/research/memory",
"experiments/proposals/model-config"
]

View File

@@ -1,66 +0,0 @@
---
summary: "Harden cron.add input handling, align schemas, and improve cron UI/agent tooling"
read_when:
- Debugging invalid `cron.add` payloads
- Aligning cron schemas across gateway, CLI, and UI
owner: "openclaw"
status: "complete"
last_updated: "2026-01-05"
title: "Cron Add Hardening"
---
# Cron Add Hardening & Schema Alignment
## Context
Recent gateway logs show repeated `cron.add` failures with invalid parameters (missing `sessionTarget`, `wakeMode`, `payload`, and malformed `schedule`). This indicates that at least one client (likely the agent tool call path) is sending wrapped or partially specified job payloads. Separately, there is drift between cron provider enums in TypeScript, gateway schema, CLI flags, and UI form types, plus a UI mismatch for `cron.status` (expects `jobCount` while gateway returns `jobs`).
## Goals
- Stop `cron.add` INVALID_REQUEST spam by normalizing common wrapper payloads and inferring missing `kind` fields.
- Align cron provider lists across gateway schema, cron types, CLI docs, and UI forms.
- Make agent cron tool schema explicit so the LLM produces correct job payloads.
- Fix the Control UI cron status job count display.
- Add tests to cover normalization and tool behavior.
## Non-goals
- Change cron scheduling semantics or job execution behavior.
- Add new schedule kinds or cron expression parsing.
- Overhaul the UI/UX for cron beyond the necessary field fixes.
## Findings (current gaps)
- `CronPayloadSchema` in gateway excludes `signal` + `imessage`, while TS types include them.
- Control UI CronStatus expects `jobCount`, but gateway returns `jobs`.
- Agent cron tool schema allows arbitrary `job` objects, enabling malformed inputs.
- Gateway strictly validates `cron.add` with no normalization, so wrapped payloads fail.
## What changed
- `cron.add` and `cron.update` now normalize common wrapper shapes and infer missing `kind` fields.
- Agent cron tool schema matches the gateway schema, which reduces invalid payloads.
- Provider enums are aligned across gateway, CLI, UI, and macOS picker.
- Control UI uses the gateways `jobs` count field for status.
## Current behavior
- **Normalization:** wrapped `data`/`job` payloads are unwrapped; `schedule.kind` and `payload.kind` are inferred when safe.
- **Defaults:** safe defaults are applied for `wakeMode` and `sessionTarget` when missing.
- **Providers:** Discord/Slack/Signal/iMessage are now consistently surfaced across CLI/UI.
See [Cron jobs](/automation/cron-jobs) for the normalized shape and examples.
## Verification
- Watch gateway logs for reduced `cron.add` INVALID_REQUEST errors.
- Confirm Control UI cron status shows job count after refresh.
## Optional Follow-ups
- Manual Control UI smoke: add a cron job per provider + verify status job count.
## Open Questions
- Should `cron.add` accept explicit `state` from clients (currently disallowed by schema)?
- Should we allow `webchat` as an explicit delivery provider (currently filtered in delivery resolution)?

View File

@@ -1,40 +0,0 @@
---
summary: "Telegram allowlist hardening: prefix + whitespace normalization"
read_when:
- Reviewing historical Telegram allowlist changes
title: "Telegram Allowlist Hardening"
---
# Telegram Allowlist Hardening
**Date**: 2026-01-05
**Status**: Complete
**PR**: #216
## Summary
Telegram allowlists now accept `telegram:` and `tg:` prefixes case-insensitively, and tolerate
accidental whitespace. This aligns inbound allowlist checks with outbound send normalization.
## What changed
- Prefixes `telegram:` and `tg:` are treated the same (case-insensitive).
- Allowlist entries are trimmed; empty entries are ignored.
## Examples
All of these are accepted for the same ID:
- `telegram:123456`
- `TG:123456`
- `tg:123456`
## Why it matters
Copy/paste from logs or chat IDs often includes prefixes and whitespace. Normalizing avoids
false negatives when deciding whether to respond in DMs or groups.
## Related docs
- [Group Chats](/channels/groups)
- [Telegram Provider](/channels/telegram)

View File

@@ -181,8 +181,6 @@ Use these hubs to discover every page, including deep dives and reference docs t
## Experiments (exploratory)
- [Onboarding config protocol](/experiments/onboarding-config-protocol)
- [Cron hardening notes](/experiments/plans/cron-add-hardening)
- [Group policy hardening notes](/experiments/plans/group-policy-hardening)
- [Research: memory](/experiments/research/memory)
- [Model config exploration](/experiments/proposals/model-config)