* initial version of a FAST pre-install skill * first round of testing * Update fast-0-org-setup-prereqs skill with improved UX and local path handling - Add explicit lockout warning and stop condition if the user is not a member of the provided Admin Principal group. - Streamline bootstrap project selection to only prompt for an override if the active gcloud project is rejected. - Restrict dataset discovery strictly to the `fast/stages/0-org-setup/datasets/` directory. - Improve location handling by referencing `defaults.schema.json` for Standard GCP and auto-configuring fixed regions for GCD. - Add comprehensive `local_path` management: prompt for customization, create directories, move `defaults.yaml` to the local data folder, and symlink `0-org-setup.auto.tfvars` back to the stage directory. * add testing scenarios, implement initial changes for scenario 2 * move skills * move to a skills/fast subfolder * Refactor fast-0-org-setup prereqs skill * Add skill-turn-harness utility tool * Use relative markdown links for skill references * Use descriptive titles for markdown links in skill references * Add descriptions to each phase in the prerequisites workflow map * Use backslash for markdown line breaks in skill map * Update README security warning to mention default .gitignore * shebang * Update fast prereqs skill rules to force sequential question flow and refine harness tool with proper ctrl+c handling and slugified log paths * Move playbook-gcp-dev.yaml to fast/prerequisites/gcp-dev.yaml and update fast prerequisites * docs(skill-turn-harness): detail autonomous pond testing approach * docs(skill-turn-harness): add final_state_checks to pond architecture and update toc * Refine fast prereqs SKILL and gcp-dev playbook to strictly align with one-question-at-a-time rule * feat(skill-turn-harness): update playbook schema for autonomous persona mode * feat(skill-turn-harness): implement autonomous persona testing mode and fallback logic * docs(skill-turn-harness): document the three modes of testing and update ToC * implement timeout, schema validation, configurable cli * chore: remove accidentally committed log files * chore: ignore logs directory * feat(skill-harness): implement tool execution interception, configurable workspace, and modularized validation * feat(skill-harness): add model configuration and update README * fix(skill-harness): automatically inject -y flag to gemini commands * docs(skill-harness): add TODO.md with analysis for skill environment dependencies * feat(skill-harness): add working_dir support and clean up fixtures - Implement working_dir in harness to run tests in specific directories. - Rename test fixtures and playbooks to be more descriptive. - Add E2E test for working_dir. - Apply code quality improvements to harness.py (imports, linting). - Update README with working directory considerations and usage notes. - Update phase3-bootstrap-and-iam.md skill doc to add execution rule against creating temp scripts. * fix: capture customer_id and respect relative paths * Implement isolated temp workspace sandboxing with symlinks in test harness * Configure GCD manual autonomous playbook and align Phase 3/4 steps order * Fix linting and schema tests failures - Add missing license headers to tools/skill-turn-harness files. - Fix trailing spaces and newlines in playbooks. - Ignore tools directory in schema tests workflow. TAG=agy CONV=1bb75453-c3e2-448b-bae9-8e332a068012 * Fix Python formatting with yapf TAG=agy CONV=1bb75453-c3e2-448b-bae9-8e332a068012 * Refactor skill-turn-harness to use Antigravity SDK - Migrated harness from gemini-cli subprocesses to Antigravity SDK. - Implemented real-time step streaming and console logging. - Added color-coded terminal output (dark gray headers, blue inputs, pink outputs). - Collapsed excessive newlines in streamed thoughts. - Excluded harness codebase from workspace copy to prevent agent cheating. - Enabled skills folder copy to resolve agent lookup loops. - Added key validation and CLI --debug flag. * Fix autonomous turn layout: print Turn ID before execution - Moved the [Autonomous Turn X] header print to before running the agent turn. - This groups the real-time thinking and tool calls under the correct Turn ID block, instead of displaying them before the label. * Remove obsolete .log.md from prerequisites skill directory
6.9 KiB
6.9 KiB
Phase 4: Configuration & Wrap-up
Step 7: Configuration Generation
- Explain Datasets: Briefly explain to the user that FAST uses "datasets" (collections of YAML files) that fully describe the design, architecture, resources, and policies applied.
- Select the Dataset: Ask the user to select the dataset they want to use for their landing zone design.
- If GCD: Explicitly state that the
classic-gcddataset must be used for GCD installations. - If Standard GCP: Offer the available datasets and ask them to choose one. Crucially, only search for available datasets within the
fast/stages/0-org-setup/datasets/directory. Do not search across the entire repository or other FAST stages. Provide a one-line description below each dataset when presenting the options (e.g., "classic: The standard FAST landing zone architecture", "hardened: A more restrictive, hardened landing zone architecture").
- If GCD: Explicitly state that the
- Explain Defaults Configuration: Explain to the user that we are starting the configuration of the
defaults.yamlfile, which drives the static configuration of the dataset by providing the Org ID, Billing ID, user-specified locations, and any static values they need to bring in from the outside (like additional IAM principals used in the YAML files to assign IAM roles). - Determine Locations: FAST uses a set of locations for different services.
- If GCD: The region is fixed based on the universe selected in Phase 1. Set the
logginglocation toglobaland all other required locations to the Universe Region. Do not ask the user to choose; simply show them the configured locations. - If Standard GCP: Check the
fast/stages/0-org-setup/schemas/defaults.schema.jsonto identify the required location keys (e.g.,bq,gcs,logging,pubsub). First, ask the user to provide a "base location" (e.g.,europe-west1), explaining that submitting without answering will confirm the default value. Even if the user confirms the base location, you must then ask if they need to override the location for any individual services.
- If GCD: The region is fixed based on the universe selected in Phase 1. Set the
- Determine Local Path: Explain to the user that FAST generates provider configurations and other files that need to be stored outside the repository. This is defined by the
output_files.local_pathsetting. Propose a default path based on the chosen prefix (e.g.,~/fast-config/<prefix>) and ask the user to confirm or provide a different path. Crucially, if the user provides a relative path (e.g.,custom-fast-configor./custom-fast-config), use it exactly as provided relative to the current working directory. Do not automatically prepend~/to their input. Once confirmed, create this directory usingmkdir -p <LOCAL_PATH>. - Ask for Additional Context: Ask the user if there are any other static values they want to bring in from outside to be referenced in the YAML files. Show them the available context keys (excluding
condition_vars). Provide examples showing that prefixes are mandatory for IAM principals (e.g.,user:foo@example.com,group:bar@example.com). For GCD, also show aprincipalSet:example. Do not use shell commands likeechoorcatto show this list; output it directly in your chat message or theask_userprompt. - Create Local Directories and Copy Defaults:
- Create the
data/0-org-setup/andproviders/directories inside the confirmedlocal_path(mkdir -p <LOCAL_PATH>/data/0-org-setup/ <LOCAL_PATH>/providers/). - Copy (do not move) the
defaults.yamlfrom the chosen dataset folder to<LOCAL_PATH>/data/0-org-setup/defaults.yamlusingcp.
- Create the
- Edit the Copied Defaults File: Use the
replacetool to edit the copied<LOCAL_PATH>/data/0-org-setup/defaults.yamlfile.- Populate
global.billing_account,global.organization.id,global.organization.domain, andglobal.organization.customer_id(using the values gathered in Phase 2). Note thatcustomer_idmay not be present for GCD. - Populate
context.iam_principals.gcp-organization-admins(using the Admin Principal determined in Phase 2). - Populate the service-specific locations gathered in the previous step into the
context.locationsblock and map them appropriately inprojects.defaults.locations. - Populate
output_files.local_pathwith the confirmed path. - If additional context was provided, add it to the
contextblock. - If GCD, ensure the
overrides.universeblock is present withdomain,prefix, and specific identity overrides.
- Populate
- Run YAML validation:
yamllint -c .yamllint --no-warnings <LOCAL_PATH>/data/0-org-setup/defaults.yaml. Handle missing tool errors as described in the Core Principles. - Create Configuration Files:
- Use
write_fileto create0-org-setup.auto.tfvarsinside thelocal_path(<LOCAL_PATH>/0-org-setup.auto.tfvars). - In
0-org-setup.auto.tfvars, set thefactories_configvariable. Thedatasetshould point to the original dataset folder (e.g.,"datasets/classic"), but thepaths.defaultsmust point to the absolute path of the copied defaults file. - If GCD, also: Create a temporary
0-org-setup-providers.tffile containing the specificuniverse_domainconfiguration usingwrite_fileat<LOCAL_PATH>/providers/0-org-setup-providers.tf.
- Use
Step 8: Organization Policy Import Check
- Explain that pre-existing organization policies can cause
409 Conflicterrors during the first apply if not imported. - Execute (or provide) the command to list current policies.
gcloud org-policies list --organization="<ORG_ID>" --format="value(constraint)" - Update
0-org-setup.auto.tfvars: If any policies are returned, capture the output, format it as an HCL list in memory, and use thereplacetool to append theorg_policies_importsvariable to the0-org-setup.auto.tfvarsfile. ABSOLUTELY NEVER use shell redirection likeecho >>,awk >>, orcat <<EOF >>to edit files. Explain to the user that this tells Terraform to import these existing policies rather than attempting to recreate them.
Step 9: Wrap-up & Apply
- Link Configuration: Instruct the user to link the final configuration files to the stage directory using the
fast-links.shscript. They should navigate tofast/stages/0-org-setup/and run:Explain that they should then copy and run the commands printed by the script to create the links. Note: If they are not on GCD, they can ignore the provider file linking command printed by the script for the first run.../../fast-links.sh <LOCAL_PATH> - Remind the user that the prerequisite phase is complete.
- Instruct them to run
terraform initandterraform apply. - Remind them to delete the temporary project and reset their gcloud default project to
iac-0after a successful apply. Provide the exact commands for them to copy and use later:gcloud projects delete <TEMP_PROJECT_ID> gcloud config set project <IAC_PROJECT_ID>