sales-demos-dev-workflowlisted

# sales-demos-dev-workflow Every code change in this repo follows the same three-step cycle. None of the steps can be skipped, and the order matters. ``` merge to main ──► config.yml --limit <env> ──► Linux Day 1 - 0 Workflow │ │ │ code lands AAP config updated full pipeline runs project synced from AAP, in the EE ``` **Why all three?** `scm_update_on_launch` is `false` on the AAP project, so launching a workflow after a merge runs whatever revision was last synced. `config.yml` is the sync. Skip it and you are testing old code and wondering why your change had no effect. ## Step 1 — Branch, PR, merge 1. **Open a GitHub issue first.** Document before fixing. Label it — run `gh label list --repo ericcames/sales.demos` and apply every label that fits. 2. **Create a worktree** (never branch in the main checkout): ```bash git worktree add ../sales.demos-<slug> <type>-<issue>-<slug> cd ../sales.demos-<slug> # examples: fix-86-preflight-vault-lookup, docs-191-dev-workflow-skill ``` `<type>` is `fix`, `docs`, or the area. `<slug>` is 2–4 words describing the change, not the file. The issue number links the branch back to the decision. 3. **Make changes, commit, push:** ```bash git push -u origin <branch> ``` 4. **Open a PR.** Include `Closes #N` in the PR body when it resolves an issue — GitHub auto-closes on merge; without it th