Skip to content

Instantly share code, notes, and snippets.

@Scheevel
Created January 5, 2026 21:36
Show Gist options
  • Select an option

  • Save Scheevel/bf85da8bb97f126054ad83a89e310c4e to your computer and use it in GitHub Desktop.

Select an option

Save Scheevel/bf85da8bb97f126054ad83a89e310c4e to your computer and use it in GitHub Desktop.
Fixed regression, archived stories, and successfully deployed web release.
↳ bmad-master
commit all changes, this is for @ 10.4.3 tag as "known good check point"
↳ deployer
*smart-deploy-web @ 9.6 @ 10.4.1 @10.4.3 Ask any clarifying questions and challenge assumptions
-
Run *analyze-web first to check the current configuration and secret status. Let me know if any questions remain.
-
First, list the commands that prompted user approval and make them available from this session for use in future sessions.
-
First add these to settings.local.json then execute the full recommended Deployment Plan.
↳ analyst
What prior story was "export" feature "View component URL" ideated in?
↳ dev
Review the "View Component URL" export feature implemented in Story 7.6: Export Component Deep Link URLs (Epic 7). The core value proposition: Generate clickable URLs in CSV/Excel exports that navigate directly to a component's location in the Drawing Viewer with auto-zoom is no longer functioning. Areas to evaluate include exportFields.ts, exportService.ts, ExportPreview.tsx The feature field was originally named component_view_link and was renamed to component_url during implementation. The story passed QA gate on October 23, 2025 after the E3 end-to-end test validated URL navigation with auto-zoom.
-
Please write a hand-off document for architecture review.
-
investigate the following error: `refresh.js:27 WebSocket connection to 'ws://localhost:8081/' failed:` which is spawned when launching the web version of the site
↳ architect
*research @ 7.6-url-export-regression-handoff
-
address the underlying architectural issue and refactor for durability
-
Draft the ExportField interface evolution
-
I want to roll back all the changes here since deciding to do this "full architectural refactor". Here was the todo list: ...
-
Now document these changes that needed to be made in the @ 7.6-url-export-regression-handoff document
↳ deployer
investigate the discrepancy between local and online dev environment. Specifically the recent `/search` updates are not visible in the web
↳ analyst
based on @ 7.6-url-export-regression-handoff do you perceive we should `elicit` further or move straight to `create-doc` with the `story-tmpl.yaml` template to prepare a new Dev Story in the `/stories/` folder?
-
#1 proceed with story creation
-
#1 proceed to next section
↳ po
*validate-story-draft @ 7.6-url-export-regression-handoff and set status to for dev start, or decide if complexity needs it to be shard
-
update story status to apporoved
↳ qa
*test-design @ 7.6.1 and update the story with your scenarios
↳ dev
*develop-story @ 7.6.1 you are authorized to begin and follow closely the QA guidance in the story
-
check docker status
↳ qa
*review and *gate based on scenarios in @ 7.6.1
↳ deployer
I've stopped all docker containers, now *smart-deploy-local @ 7.6.1
↳ dev
We've run into this problem before. When deployed only locally, the base URL use used for the permalink is the production domain and not the local host. In this case it is https:... instead of https:...
↳ bmad-master
Archive all 7.6.1 stories and the collateral that may exist in `/architecture` or `/mockups` or `/qa` or `/stories`
1. Review git changes for this and all related to these documents (git diff, git status)
2. Update @docs/completed-epics.md:
- Add this story to the epic's "Stories Completed" list
- Update "Key Files Created/Modified" if significant architecture changes
3. Remove the story markdown file, once it has been consolidated into the completed-epics.md.
4. Clean up all other story collateral that is no longer needed, and clean up old planning docs with similar numbering.
Note: do remove any documents from `/keep` folder.
Ask me any clarifying questions before beginning.
-
#1-#3 Git commit the current untracked files, then continue with archival. Testing has completed successfully for this regression feature. #4 simply skip
↳ analyst
evaluate the "doneness" of @ 9.6 @ 10.4.1 and @ 10.4.3
↳ qa
*review and *gate based on scenarios in @ Story @ 10.4.3 Path to Done
Current: Ready for Review (Gate: CONCERNS)
Step 1: QA re-validates TEST-002/003/004 fixes
Step 2: Gate updated to PASS
↳ bmad-master
Archive all @ 9.6 @ 10.4.1 and @ 10.4.3 stories and the collateral that may exist in `/architecture` or `/mockups` or `/qa` or `/stories`
1. Review git changes for this and all related to these documents (git diff, git status)
2. Update @docs/completed-epics.md:
- Add this story to the epic's "Stories Completed" list
- Update "Key Files Created/Modified" if significant architecture changes
3. Remove the story markdown file, once it has been consolidated into the completed-epics.md.
4. Clean up all other story collateral that is no longer needed, and clean up old planning docs with similar numbering.
Note: do NOT remove any documents from `/keep` folder.
Ask me any clarifying questions before beginning.
-
#1 review then delete
#2 correct
#3 proceed with archival
#4 follow your pattern
#5 yes, sorry for the confusion. Do NOT remove documents from `/keep`
↳ architect
Update @docs/architecture/database-schema.md to reflect as-built. Verify BOTH the ERD diagram and detailed table specifications are consistent
-
Chat me up on API Machine Auto-Stop Behavior. The API machine is currently stopped (due to auto_stop_machines = "stop" in .toml). This is expected behavior to save costs when there's no traffic. Confirm for me that the API will auto-start when accessing https: ... dev.
↳ deployer
In preparation to *smart-deploy-web run *analyze-web first to check the current ... configuration and secret status. Let me know if any questions remain. Ask any clarifying questions and challenge assumptions
-
#1 confirmed accurate behavior
#2 Correct, deploy all functionality
#3 Correct
#4 Yes, we should be using explicit config variables
#5 Yes, document the rollback commands before Deployment
-
Looks good, proceed with *smart-deploy-web now
-
Yes, commit the configuration changes to git.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment