-
-
Architecture: Gemini + Google ADK planning, approval gate, Cloud Run execution, WordPress REST, and Firestore evidence.
Inspiration
What it does
How we built it
Challenges we ran into
Accomplishments that we're proud of
What we learned
What's next for Taskmaster: A WordPress Completion Agent
Inspiration
A half-finished WordPress redesign is rarely one clean bug. Old and new page builders coexist, demo copy survives on public pages, nobody remembers what was finished, and deleting the wrong “unused” page can erase years of business history.
Our real test case is a Greek dog trainer's site originally built in 2015 and now caught midway through a redesign: legacy WPBakery pages remain alongside newer Elementor pages. The submitted fixture is sanitised, but it keeps the structural mess that makes the problem real: 4,695 wp_posts records, 308,675 wp_postmeta rows, and 41 pages across statuses in the authenticated inventory.
The problem was not generating more copy. It was completing a site-wide operational workflow without silently destroying what already worked.
What it does
WordPress Completion Agent turns that unfinished redesign into a bounded workflow:
- Survey every page through authenticated WordPress REST.
- Classify builders, shortcodes, status, demo markers, and visible-text evidence in deterministic code.
- Use a Google ADK planner with Gemini 3.5 Flash to create a typed task for every surveyed page.
- Persist the plan in Firestore and wait for explicit operator decisions.
- Start a Cloud Run Job and return immediately, so execution can continue in the background.
- Execute only approved tasks: propose, guard, apply, read back, verify, and restore on failure.
- Store durable progress, checks, diffs, and outcomes in Firestore.
The current plan contains 23 migrations, 2 demo-copy cleanups, 3 recoverable trash candidates, and 13 preserves. Posts and custom post types remain inventory; they are not claimed as completed.
How we built it
Gemini decides what kind of work a page needs. Deterministic code performs the WPBakery conversion. Gemini-assisted cleanup returns exact demo fragments, and code removes only verbatim matches.
Google ADK 2.7.0 owns the planning loop that creates the executable artifact. Its session keeps the survey available across retries and continuations; typed tools accept validated task batches; finish_plan refuses an incomplete inventory; and a bounded RunConfig stops runaway model calls.
The deployed system uses a Cloud Run Job for asynchronous planning and execution, Cloud Run services for the control plane and sanitised WordPress fixture, Firestore for plans and outcomes, and Cloud Build plus Artifact Registry for deployment. The executor talks to WordPress only through narrow REST capabilities; it never connects directly to the database.
The public control plane deliberately exposes persisted evidence without exposing write authority. Approval, target, and run controls are disabled there, and direct POST attempts are rejected. The demo starts a fresh execution from an authenticated Google Cloud session.
Safety by design
- Silence is not consent: pending and rejected tasks are untouched.
- Approvals are bound to the exact plan reviewed; replanning returns changed work to pending.
- Delete means recoverable WordPress trash and requires explicit title evidence.
- Dry run never calls the trash endpoint.
- Cleaning accepts only verbatim fragments and refuses changes over 35% of a page.
- Migration must preserve every visible character.
- Unknown plugin shortcodes remain verbatim and are reported as dependencies.
- Every write is read back from WordPress and checked again.
- Failed checks restore original content and changed builder metadata, then verify the restoration.
- A failed URL or 404 is unavailable-route evidence, never evidence that content should be deleted.
Results
One deployed planning run created all 41 tasks through five ADK tool calls. A separate live Cloud Run execution applied and verified two approved migrations: 2 of 2 successful.
A read-only measurement converts all 23 WPBakery pages in the reset fixture in memory for both Elementor and native-block targets:
- 23 of 23 migrate without losing visible text.
- 0 retain WPBakery layout shortcodes.
- Plugin-owned sliders, maps, and portfolio shortcodes are preserved instead of guessed.
After the recorded two-page demo, the same check reports 22 of 22. Page #2306 leaves the migration set; page #230 remains in the broad candidate set only because its plugin-owned vc_gmaps shortcode is intentionally preserved. This proves structural migration and text preservation, not pixel-perfect visual equivalence.
Challenges and lessons
An early model-based rewrite returned only 7% of one page. That changed the architecture. WPBakery is a grammar, so migration became a parser and emitter; the model decides the action but does not rewrite the page.
The truncated page initially passed its acceptance criteria because nobody had written “keep all visible text.” Preservation is now an unconditional guard.
WordPress can filter content after a write. The executor therefore verifies what WordPress stored, not what the client sent, and restores both content and builder metadata if the stored result fails.
Approval also had to name the exact artifact reviewed. A page/action key alone allowed a new plan to inherit an old approval. Decisions are now bound to plan_id and fail closed after replanning.
The sharpest lesson was simple: put the model where judgement lives, not where parsing lives.
Data and privacy
The fixture is derived from a pre-existing production site, but account, contact and reviewer data, credentials, real photographs, API keys, private keys, and developer-home paths were removed. Repository and reachable-history audits pass before publication.
Pre-existing work disclosure
The Argus Dog site, its content, branding, photography, and production redesign predate the hackathon and are not submitted as hackathon output. The agent project was built during the submission period and uses a sanitised structural fixture as its real-world test case. The earlier read-only phase1 prototype remains as audit evidence; the submitted Taskmaster execution path is phase2, job.py, the control plane, Firestore, and Cloud Run.
What's next
The next proofs are screenshot-based visual comparison, a second independent WordPress installation, and carefully extending execution beyond pages. Until then, unsupported plugin structures stay visible and unresolved. Honest incompleteness is safer than confident deletion.
Log in or sign up for Devpost to join the conversation.