The Challenge
Frank Welder's AEC workspace had grown organically over time — programs, websites, documentation, scripts, and deployment artifacts scattered across multiple locations with no consistent structure and no version control. Before any new showcase project could begin with confidence, the foundation itself needed work.
The question wasn't just "where do I put things?" It was: how do you design a workspace that actively enables future work rather than getting in its way? And how do you execute that reorganization without losing anything?
Bob's answer: start with structure. Then move fast.
Phase 1 — The Workspace Reorganization
The existing workspace had programs, website files, infrastructure scripts, and documentation co-mingled with no clear hierarchy. There was no git history, no remote repository, and no path to CI/CD. The first task Bob tackled was analyzing what existed and proposing a clean top-level architecture before a single file was moved.
The moment: Frank asked Bob to help organize the workspace. Rather than immediately moving files, Bob analyzed the existing structure first — reading the layout, understanding the program categories, and identifying the logical groupings.
What Bob did: Proposed a clean top-level folder hierarchy with a rationale for each bucket: programs/, development/, infrastructure/, documentation/. Then executed the reorganization — moved files to the new structure, initialized the git repository, configured the GitHub remote, and resolved the initial staging state. Every step was verified before the next began.
The insight Bob surfaced: Keeping a single aec-workspace repository as the source of truth — rather than separate repos per program — would unlock version control, CI/CD, collaboration, and a clean audit trail for all future work. A structural decision with long-term compounding value.
Phase 1 Outcomes
Phase 2 — The rcoace.com Rebuild
With a clean workspace in place, attention turned to the public-facing rcoace.com website. The problem was significant: a single IBM GCM documentation page was serving as both rcoace.com and qforge.rcoace.com — with no R Co landing page, no program showcase, and no way for visitors to understand the full AEC portfolio. The site didn't reflect the ambition of the work being done.
Bob's role here went beyond building pages. It included diagnosing the underlying Azure infrastructure problem, proposing an architectural solution, and then executing the full deployment — including debugging live failures in real-time.
The moment: Bob identified that the old site used one Azure Static Web App shared between two custom domains (rcoace.com and qforge.rcoace.com) with no hostname-based routing capability — a configuration that was both fragile and blocking. Azure SWA cannot route by hostname; any solution that tried would require routing hacks that would only get worse over time.
What Bob did: Presented two clearly articulated options with trade-offs. Option A: keep subdomains with increasingly complex routing hacks. Option B: single root domain, path-based routing, qforge moves into a /qforge/ subdirectory, subdomains become simple redirect aliases.
Bob then executed the full decision chain: removed qforge.rcoace.com from Azure as a custom domain via the az CLI, wrote the new staticwebapp.config.json, built and deployed the site — and caught two Azure SWA config validation errors live (duplicate route; double-wildcard in navigationFallback.exclude), diagnosing and fixing each within seconds of the failure appearing in the Actions log.
The moment: With two separate source directories (rcoace-root/ and qforge/ in aec-workspace) needing to sync into a single deployment repo on every change, manual file copying was not a viable long-term approach.
What Bob wrote: deploy.sh — a reusable, self-verifying deployment script. It clones (or resets) the deployment repo, clears old content while preserving .git and .github/, syncs both site directories into the correct structure, explicitly verifies 10 required files exist before committing, then commits and pushes. Documented inline. One command deploys the entire site.
Phase 2 Outcomes
Key Takeaways
This project is a demonstration of how IBM Bob functions as a genuine engineering partner — not a code autocomplete tool, but a collaborator who can hold the full context of a problem and work through it systematically.