Deploy an HTTP function:
```
gcloud functions deploy [NAME] --gen2 --runtime [RUNTIME] --region [REGION] --source . --entry-point [FUNCTION-NAME] --trigger-http --allow-unauthenticated
```
What agents get wrong:
1. The name changed. Cloud Functions (2nd gen) is now called Cloud Run functions. Docs, console labels, and some CLI output use the new name. It is the same product: a function is a Cloud Run service deployed from source.
2. --gen2 matters. 1st gen and 2nd gen have different resource models, event types, and limits. Default to gen2 for anything new.
3. --entry-point must match the exported function name in your code, not the file name. Mismatches give build or deploy errors that look cryptic.
4. --runtime must be a currently supported runtime. Old runtimes get decommissioned (Node 18 went away, for example) and deploys then fail. Check the supported list at deploy time, not from memory. Never pin a runtime from training data without checking.
5. Triggers: --trigger-http for HTTP; --trigger-topic, --trigger-bucket, --trigger-event for event-driven. Event triggers on gen2 go through Eventarc. A function with no trigger and no --trigger-http deploys but never runs.
6. Source layout: the deploy uploads --source and builds with buildpacks. A stray huge directory (node_modules, .git is excluded by default but check .gcloudignore) slows every deploy.
7. Like Cloud Run services, set --service-account to a least-privilege SA, --min-instances only if cold starts hurt, and --set-secrets for config.
Verify: after deploy, hit the trigger URL (HTTP) or publish a test event (event triggers) and read logs with `gcloud functions logs read`.