docs(state): close n8n wip and seed drive docs sheets plan
This commit is contained in:
80
WIP.drive-docs-sheets.md
Normal file
80
WIP.drive-docs-sheets.md
Normal 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.
|
||||
Reference in New Issue
Block a user