Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions domain-skills/google-cloud/service-accounts.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
# Google Cloud Console — service accounts & API keys

@cubic-dev-ai cubic-dev-ai Bot Jul 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: The title says 'service accounts & API keys', but the document only covers service accounts and service account keys. In Google Cloud, API keys and service account keys are distinct credential types, and conflating them in the title can mislead readers into looking for the wrong credential type. Consider updating the title to something like # Google Cloud Console — service accounts & service account keys to match the content.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At domain-skills/google-cloud/service-accounts.md, line 1:

<comment>The title says 'service accounts & API keys', but the document only covers service accounts and service account keys. In Google Cloud, API keys and service account keys are distinct credential types, and conflating them in the title can mislead readers into looking for the wrong credential type. Consider updating the title to something like `# Google Cloud Console — service accounts & service account keys` to match the content.</comment>

<file context>
@@ -0,0 +1,15 @@
+# Google Cloud Console — service accounts & API keys
+
+## Deep links (skip all menu navigation)
</file context>
Suggested change
# Google Cloud Console — service accounts & API keys
# Google Cloud Console — service accounts & service account keys
Fix with cubic


## Deep links (skip all menu navigation)

- Enable an API: `https://console.cloud.google.com/apis/library/<service>.googleapis.com?project=<PROJECT_ID>` — one `Enable` button, redirects to the API overview when done.
- Create a service account: `https://console.cloud.google.com/iam-admin/serviceaccounts/create?project=<PROJECT_ID>`
- Keys page for an SA: `https://console.cloud.google.com/iam-admin/serviceaccounts/details/<SA_UNIQUE_ID>/keys?project=<PROJECT_ID>` — the unique id is shown as "OAuth 2 Client ID" in the SA list right after creation.

## Traps

- The console URL after login includes the currently selected project as `?project=...` — reuse it instead of asking the user which project to use for throwaway integrations.
- SA creation: typing the display name auto-fills the account ID; the resulting email is shown live under the ID field (`<id>@<project>.iam.gserviceaccount.com`). Grab it from there — you need it to share resources with the SA.
- "Create and close" (skip steps 2–3) is enough when access will be granted by sharing a resource (e.g. a Google Sheet) rather than IAM roles.
- Key creation: Add key → Create new key → JSON (preselected) → Create. The JSON downloads silently to `~/Downloads/<project>-<hex>.json` — no save dialog. Poll `ls -t ~/Downloads/<project>-*.json`.
- Sheets/Drive access for an SA needs NO project roles: just share the document with the SA's email as Editor. The SA can't accept invites; sharing is enough.

@cubic-dev-ai cubic-dev-ai Bot Jul 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: The document currently recommends sharing Sheets/Drive documents with the service account as Editor without any qualification about the actual access needed. For read-only integrations (such as reading dropdown validation via the API), Editor is broader than necessary and violates least-privilege practice. Since this document is a copy-paste-ready domain-skills guide, consider qualifying the recommendation so readers match the share role (Viewer, Commenter, or Editor) to the operations the integration actually performs.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At domain-skills/google-cloud/service-accounts.md, line 15:

<comment>The document currently recommends sharing Sheets/Drive documents with the service account as Editor without any qualification about the actual access needed. For read-only integrations (such as reading dropdown validation via the API), Editor is broader than necessary and violates least-privilege practice. Since this document is a copy-paste-ready domain-skills guide, consider qualifying the recommendation so readers match the share role (Viewer, Commenter, or Editor) to the operations the integration actually performs.</comment>

<file context>
@@ -0,0 +1,15 @@
+- SA creation: typing the display name auto-fills the account ID; the resulting email is shown live under the ID field (`<id>@<project>.iam.gserviceaccount.com`). Grab it from there — you need it to share resources with the SA.
+- "Create and close" (skip steps 2–3) is enough when access will be granted by sharing a resource (e.g. a Google Sheet) rather than IAM roles.
+- Key creation: Add key → Create new key → JSON (preselected) → Create. The JSON downloads silently to `~/Downloads/<project>-<hex>.json` — no save dialog. Poll `ls -t ~/Downloads/<project>-*.json`.
+- Sheets/Drive access for an SA needs NO project roles: just share the document with the SA's email as Editor. The SA can't accept invites; sharing is enough.
</file context>
Fix with cubic

16 changes: 16 additions & 0 deletions domain-skills/google-sheets/sharing-and-api.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
# Google Sheets — sharing dialog & API-first workflows

## Share a sheet with a service account

Share button (top right) → type the SA email → pick the autocomplete entry → chip appears with a role dropdown (defaults to Editor) → optionally uncheck "Notify people" (SAs can't read mail) → `Share`.

- **Workspace orgs show an external-share interstitial** ("...is external to <org>... Share anyway?"). Click `Share anyway`, which returns you to the share dialog — you must click `Share` AGAIN. The dialog closing is the success signal.
- Trap: after the dialog closes, stray clicks land on the grid and put a cell into edit mode. If that happens press Escape (twice is safe) — verify the formula bar shows the original value before moving on.

## Prefer the API over DOM scraping

The Sheets grid is canvas-rendered — DOM selectors are useless for cell data. Once a service account (or OAuth token) exists, read/write via `sheets.googleapis.com/v4` with plain `fetch`; a service-account JWT is ~20 lines of `node:crypto`/`python` with scope `https://www.googleapis.com/auth/spreadsheets`, no SDK needed.

- Read dropdown (data validation) options without clicking anything: `GET /v4/spreadsheets/<id>?ranges=Sheet1!B2:B2&includeGridData=true&fields=sheets.data.rowData.values.dataValidation` → `ONE_OF_LIST` values. `strict: true` means unlisted values are rejected chips.
- Track "your" rows robustly with **row-level developer metadata** (`createDeveloperMetadata` on a ROWS dimensionRange, then `POST /developerMetadata:search`). Row numbers shift when humans sort/insert/delete; metadata moves with the row. `values.append` returns `updates.updatedRange` — parse the row number from it to tag the row you just appended.
- The sign-in wall (`accounts.google.com/v3/signin`) means the whole Chrome profile is logged out, not just Sheets — stop and ask the user; there may be no account chooser at all.