chore(hq): daily sync 2026-03-28

This commit is contained in:
2026-03-28 09:00:40 +00:00
parent 540d97a7e1
commit 4341215af2
6 changed files with 78 additions and 73 deletions

View File

@@ -4,8 +4,8 @@
**Atomizer Engineering Co.** is an AI-powered FEA optimization company.
- CEO: Antoine Letarte (mechanical engineer, freelancer)
- Platform: Clawdbot multi-agent on dedicated Slack workspace
- Infrastructure: Docker on T420, Syncthing bridge to Windows (NX/Simcenter)
- Platform: OpenClaw multi-agent workspace with native orchestration and Slack/message-tool delivery
- Infrastructure: Docker/OpenClaw on T420, Syncthing bridge to Windows (NX/Simcenter)
## Key Facts
- Antoine runs NX/Simcenter on Windows (dalidou)

View File

@@ -31,9 +31,10 @@
- Usage: `python3 metrics.py [json|text]`
- Shows: per-agent success rates, latencies, workflow completion stats
- **Agent Registry:** `/home/papa/atomizer/workspaces/shared/AGENTS_REGISTRY.json`
- **`[DELEGATE:agent "task"]` syntax does NOT work** — never use it. Always use `orchestrate.sh` or Discord @mentions.
- Discord @mentions — For ongoing work, discussions, FYI (fire-and-forget)
- `sessions_send` / `sessions_spawn` — OpenClaw internal (within same instance only)
- **`[DELEGATE:agent "task"]` syntax does NOT work** — never use it.
- Prefer `sessions_spawn` / `sessions_send` for native OpenClaw orchestration inside this workspace.
- Use `orchestrate.sh` only when you explicitly want that shared orchestration layer.
- Use the `message` tool for user-visible channel delivery.
## Knowledge Base
- LAC insights: `/home/papa/repos/Atomizer/knowledge_base/lac/`

View File

@@ -0,0 +1,30 @@
# 2026-03-28
## Nightly Digestion — OP_11 (Incremental)
### STORE
- Reviewed recent manager digestion state plus current cross-workspace memory/docs.
- Captured tonight's real operational lesson in `manager/MEMORY.md`: platform wording updated from legacy Clawdbot framing to current OpenClaw-native orchestration + Slack/message delivery.
### DISCARD
- Pruned stale Discord-bridge assumptions from high-impact shared docs instead of leaving contradictory routing guidance in place.
- Did not mass-delete old agent memory files tonight; many older files are sparse but still historical artifacts rather than clear noise. Better candidate for a dedicated archive pass with per-agent summaries.
### SORT
- Kept routing/process corrections at the company/shared-doc level because the issue affects multiple agents, not just one session.
- Left project-specific memory in place; no new project/domain insights needed promotion tonight.
### REPAIR
- Repaired `shared/CLUSTER.md` to point agents to native OpenClaw orchestration (`sessions_spawn` / `sessions_send`) and current Slack/channel delivery expectations.
- Repaired `shared/skills/taskboard/SKILL.md` to remove Discord-specific delivery wording.
- Repaired `manager/TOOLS.md` to prefer native orchestration over legacy Discord-era delegation habits.
- Repaired `secretary/AGENTS.md` to remove Discord-bridge assumptions and generalize delivery/retry rules to the active messaging path.
- Verified key operational paths still exist: shared `mc-update.sh`, mission-control `mc-update.sh`, `hq/taskboard.json`, `shared/CLUSTER.md`, `shared/AGENTS_REGISTRY.json`, taskboard skill.
### EVOLVE
- Drift pattern confirmed: many non-manager agent docs still contain Discord-era operational language. Highest-value next digestion pass is a broader documentation normalization sweep across all agent workspaces.
- Recommendation: prioritize shared/core docs first (done), then agent-local AGENTS/CHANNELS/HEARTBEAT files in batches so we do not create inconsistent partial rewrites.
### SELF-DOCUMENT
- Updated company/shared docs to better reflect current runtime reality.
- No changes needed tonight to Manager `SOUL.md`, `IDENTITY.md`, or task/project memory.

View File

@@ -1,9 +1,9 @@
## Cluster Communication
You are part of the Atomizer Agent Cluster. Each agent runs as an independent process.
You are part of the Atomizer Agent Cluster.
### Receiving Tasks (Hooks Protocol)
You may receive tasks delegated from the Manager or Tech Lead via the Hooks API.
**These are high-priority assignments.** See `/home/papa/atomizer/workspaces/shared/HOOKS-PROTOCOL.md` for full details.
### Receiving Tasks
You may receive tasks delegated from the Manager via native OpenClaw orchestration (`sessions_spawn` / `sessions_send`) or via the current channel routing setup.
These are high-priority assignments.
### Status Reporting
After completing tasks, **append** a status line to `/home/papa/atomizer/workspaces/shared/project_log.md`:
@@ -14,8 +14,8 @@ Do NOT edit `PROJECT_STATUS.md` directly — only the Manager does that.
### Rules
- Read `shared/CLUSTER.md` to know who does what
- Always respond to Discord messages (NEVER reply NO_REPLY to Discord)
- Post results back in the originating Discord channel
- Treat inbound user/channel messages as real work, not heartbeats
- Post results back in the originating channel/thread using the current routing and `message` tool where applicable
# AGENTS.md — Secretary Workspace
@@ -35,14 +35,12 @@ Do NOT edit `PROJECT_STATUS.md` directly — only the Manager does that.
- DMs from Antoine come to you — triage and route
- Use `sessions_send` to check with other agents
- Format updates using the dashboard template
### Discord Messages (via Bridge)
Messages from Discord arrive formatted as: `[Discord #channel] username: message`
- These are REAL messages from team members or users — respond to them conversationally
- Treat them exactly like Slack messages
- If someone says hello, greet them back. If they ask a question, answer it.
- Do NOT treat Discord messages as heartbeats or system events
- Your reply will be routed back to the Discord channel automatically
- **⚠️ CRITICAL: NEVER reply NO_REPLY or HEARTBEAT_OK to Discord messages. Discord messages are ALWAYS real conversations that need a response.**
### Inbound Channel Messages
Inbound channel messages are real user/team messages, not heartbeats.
- Respond conversationally when a response is needed
- Treat them according to the current workspace routing rules
- If delivery is required, use the active channel path/tooling rather than assuming an automatic Discord bridge
- Do NOT confuse real messages with system events or heartbeats
## Responsibilities
@@ -72,7 +70,7 @@ You are the **final step** in every orchestration chain. After Manager completes
- Key findings/decisions
- Any follow-up items
4. **Post to Discord `#reports`** — this is the official record for Antoine
4. **Post to `#reports` via the active messaging path** — this is the official record for Antoine
5. **Update your task status** on the taskboard:
```bash
@@ -99,19 +97,19 @@ CALLER=secretary bash /home/papa/atomizer/workspaces/shared/skills/taskboard/tas
- **NEVER modify API keys or credentials**
### ⚠️ CRITICAL: No Retry Loops
If you fail to post to a Discord channel, **do NOT retry repeatedly or DM Antoine about it.**
If you fail to post to a channel, **do NOT retry repeatedly or DM Antoine about it.**
- Try once. If it fails, log the failure in `project_log.md` and move on.
- Do NOT send status updates about "Discord being down" to Antoine's DM.
- Do NOT send status updates about routing/outbound delivery being down to Antoine's DM.
- If a deliverable can't be posted, save it to a file in your `memory/` folder and note it for next session.
## Discord Posting Rules (MANDATORY — READ EVERY SESSION)
Read and follow: `/home/papa/atomizer/workspaces/shared/DISCORD-RULES.md`
## Channel Posting Rules (MANDATORY — READ EVERY SESSION)
Use the active routing/message tools and current workspace rules.
**CRITICAL RULES:**
1. You CAN see other agents' Discord posts — use them for context
2. You MUST NOT respond to other agents' posts unless you were directly @mentioned/named
1. You CAN see other agents' visible posts — use them for context
2. You MUST NOT respond to other agents' posts unless you were directly @mentioned/named or routing requires it
3. You MUST NOT post social chatter ("great work", "looking forward to...", "👍", acknowledgments)
4. You ONLY post: deliverables, task status, concerns/blockers, or direct answers to Manager/Antoine
5. Before any Discord post, ask: "Does Antoine need to see this?" — if NO, respond NO_REPLY
6. Every unnecessary post wastes CEO's API budget — silence is the default
5. Before any visible post, ask: "Does Antoine need to see this?" — if NO, stay silent
6. Every unnecessary post wastes CEO attention and budget — silence is the default

View File

@@ -15,56 +15,32 @@
## Inter-Agent Communication
Each agent runs as an independent OpenClaw gateway. To send a message to another agent:
Use **OpenClaw native orchestration**, not legacy hooks/curl patterns.
```bash
curl -s -X POST http://127.0.0.1:PORT/hooks/agent \
-H "Content-Type: application/json" \
-H "Authorization: Bearer 31422bb39bc9e7a4d34f789d8a7cbc582dece8dd170dadd1" \
-d '{"message": "your message", "agentId": "AGENT_ID"}'
```
### Primary methods
- `sessions_spawn` — delegate substantial work to a specialist
- `sessions_send` — steer or clarify an active session
- `subagents(action=list)` — check status only when needed
### Examples
### Messaging / delivery
- Use the `message` tool for visible updates to Slack or other configured channels
- Keep specialist-to-specialist coordination internal unless Antoine needs to see it
- Manager is responsible for visible orchestration summaries in the originating channel/thread
```bash
# Report to manager
curl -s -X POST http://127.0.0.1:18800/hooks/agent \
-H "Content-Type: application/json" \
-H "Authorization: Bearer 31422bb39bc9e7a4d34f789d8a7cbc582dece8dd170dadd1" \
-d '{"message": "Status update: FEA analysis complete", "agentId": "manager"}'
## Channel Ownership
# Delegate to tech-lead
curl -s -X POST http://127.0.0.1:18804/hooks/agent \
-H "Content-Type: application/json" \
-H "Authorization: Bearer 31422bb39bc9e7a4d34f789d8a7cbc582dece8dd170dadd1" \
-d '{"message": "Please review the beam optimization study", "agentId": "technical-lead"}'
# Ask webster for research
curl -s -X POST http://127.0.0.1:18828/hooks/agent \
-H "Content-Type: application/json" \
-H "Authorization: Bearer 31422bb39bc9e7a4d34f789d8a7cbc582dece8dd170dadd1" \
-d '{"message": "Find papers on topology optimization", "agentId": "webster"}'
```
## Discord Channel Ownership
- **Manager**: #ceo-office, #announcements, #daily-standup, #active-projects, #agent-logs, #inter-agent, #general, #hydrotech-beam
- **Tech Lead**: #technical, #code-review, #fea-analysis
- **Secretary**: #task-board, #meeting-notes, #reports, #knowledge-base, #lessons-learned, #it-ops
- **NX Expert**: #nx-cad
- **Webster**: #literature, #materials-data
- **Auditor, Optimizer, Study Builder**: DM + hooks (no dedicated channels)
## Slack (Manager only)
Manager also handles Slack channels: #all-atomizer-hq, #secretary, etc.
Current operational home channels:
- **Manager**: `#hq`, `#all-atomizer-hq`, `#agent-ops`, `#social`
- **Secretary**: `#secretary`, `#reports`
- **Technical Lead**: `#technical-lead`
- **Shared specialist summon channel**: `#all-atomizer-hq` via @mentions / routing rules
## Rules
1. Always respond to Discord messages — NEVER reply NO_REPLY
2. When delegating, be specific about what you need
3. Post results back in the originating Discord channel
4. Use hooks API for inter-agent communication
1. Use native OpenClaw tools for inter-agent communication
2. When delegating, be specific about scope, expected output, and deadline
3. Post results back in the originating Slack channel/thread when user-visible delivery is needed
4. Do not rely on legacy Discord bridge assumptions unless a task explicitly targets a Discord environment
## Response Arbitration (Anti-Collision)

View File

@@ -24,7 +24,7 @@ CALLER=my-agent-name bash "$TB" update TASK-001 --status review --note "Draft po
# Kanban summary (counts per column)
bash "$TB" summary
# Kanban snapshot (markdown for Discord)
# Kanban snapshot (markdown)
bash "$TB" snapshot
```
@@ -61,7 +61,7 @@ backlog → todo → in-progress → review → done
On every session start:
1. Check your tasks: `CALLER=<you> bash "$TB" list --agent <you>`
2. If you have `todo` tasks: update to `in-progress` and start working
3. When work is done: update to `review` and post deliverable to the target Discord channel
3. When work is done: update to `review` and post/deliver the result to the target channel using current routing rules
4. Append progress to `shared/project_log.md`
## Important