docs(state): close n8n wip and seed drive docs sheets plan

This commit is contained in:
zap
2026-03-12 21:39:34 +00:00
parent 00cdbbb654
commit e6b9844097
4 changed files with 142 additions and 8 deletions

80
WIP.drive-docs-sheets.md Normal file
View File

@@ -0,0 +1,80 @@
# WIP.drive-docs-sheets.md
## Status
Status: `proposed`
Owner: `zap`
Opened: `2026-03-12`
## Purpose
Evaluate whether the n8n Google Workspace action bus should expand beyond Gmail + Calendar into Drive / Docs / Sheets, or whether those surfaces should stay direct-tool-only for now.
## Decision goal
Produce a clear go / no-go per surface:
- Google Drive
- Google Docs
- Google Sheets
## Why this is a separate WIP
Gmail + Calendar are now implemented, deployed, and smoke-tested. Drive / Docs / Sheets are a different decision because they can easily sprawl into broad CRUD coverage without the same immediate operator value.
## Constraints carried forward
- Keep `openclaw-action` as the narrow authenticated ingress.
- Keep approval/history/state in n8n.
- Use the host-side `gog` bridge for execution when appropriate.
- Preserve the compact operator contract:
- `pending_compact`
- `history_compact`
- `operator.summary_line`
- `operator.execution_state`
- `operator.result_refs`
- Keep approval defaults explicit by family.
- Default to the smallest useful verb set.
## Questions to answer
### Drive
Possible useful verbs:
- `search_drive_files`
- `list_drive_files`
- `get_drive_file_metadata`
- `move_drive_file`
- `trash_drive_file`
Questions:
- Is Drive mainly a discovery/search surface here, or do we need mutating file-management actions?
- Would direct `gog drive ...` usage be simpler than queueing through n8n for most cases?
### Docs
Possible useful verbs:
- `create_doc`
- `append_doc_text`
- `replace_doc_text`
- `get_doc_text`
Questions:
- Do we actually need approval-gated doc writes, or is docs work better done directly in a focused tool flow?
- Is append/replace enough, or would structured range operations be needed too soon?
### Sheets
Possible useful verbs:
- `read_sheet_range`
- `append_sheet_rows`
- `update_sheet_cells`
- `create_sheet_tab`
Questions:
- Is Sheets the highest-leverage next action surface because it fits queueable structured writes?
- If yes, what is the minimum safe starter set?
## Initial recommendation
- **Drive:** probably `no` for broad action-bus expansion right now; maybe `yes` for a tiny read/search surface later.
- **Docs:** probably `no` for now unless a very specific document-drafting workflow appears.
- **Sheets:** strongest `maybe yes` candidate because append/update flows map well to approval + audit history.
## Success criteria
- One-page recommendation covering Drive / Docs / Sheets.
- Clear go / no-go per surface.
- If any surface is greenlit, define only the minimum starter verbs.
- If any surface is greenlit, specify approval defaults (`low` read-only vs `high` mutating) before implementation begins.
## If implemented later
Use a fresh implementation session and promote the chosen scope into `WIP.md` before coding.