A spec agreed last session, built from a one-line go-ahead

You agreed a build spec in a previous session. You don’t want to re-explain it — you want to say go.

So the brief here is one line. WPOS opens already knowing what is queued: a theme, then the images, then eight sections one at a time, agreed earlier and waiting to be built. It names the shape of the work back before starting.

It checked its own widget library first — and decided against reuse. Nothing already built scored high enough against this design, so all eight sections were made new. Worth noting that the check happened at all: the cheap move is to force an existing widget to fit and call it efficiency.

Then it built in order: theme tokens, sixteen generated images, then the sections — hero, marquee, gallery, services, process, stats, feed and contact — smoke-testing each template before placing it.

Every image is generated — including the founder portrait. The reference had a real person on it. WPOS generated a portrait rather than reusing that photograph, because a real individual’s likeness is not an asset to borrow.

And the social links point nowhere on purpose. Wiring them to the reference’s actual accounts would have looked more finished and sent visitors to somebody else’s profiles. It chose the dead link and said why.

Three platform faults were caught during the build. The most useful: WordPress silently rewrites a double ampersand inside widget JavaScript, which breaks the script outright — with no visible error to explain it.

• Eight sections — hero, marquee, gallery, services, process, stats, feed, contact
• Sixteen generated images plus a full theme
• The existing widget library checked for reuse before anything new was built
• Each template smoke-tested before placement
• Zero console errors
• Three platform faults caught mid-build, including WordPress breaking its own widget JavaScript
• A generated founder portrait rather than a real person’s photograph
• Social links pointed nowhere rather than at someone else’s accounts

What this build actually used.

• Platform: WordPress with WPOS, eight sections
• Session memory: the plan carried between sessions — the new session opened already knowing the queued theme, images and section order, so the brief was one sentence
• Widget reuse: the existing library scored against this design before anything new was built; nothing was close enough, so all eight sections were made fresh
• Theme: theme tokens laid first, then imagery, then sections in order
• Imagery: sixteen generated images — including the founder portrait, generated rather than reusing the real person’s photograph from the reference
• Sections: hero, marquee, gallery, services, process, stats, feed and contact
• Testing: each template smoke-tested before it was placed
• Debugging: WordPress silently rewriting a double ampersand inside widget JavaScript, which breaks the script outright with no visible error
• Deliberate dead links: social links pointed nowhere rather than at the reference’s real accounts

Does WPOS remember a plan between sessions?

Yes. Here the spec was agreed in an earlier session, and the new session opened already knowing what was queued — so the brief was a single sentence.

Does it reuse existing widgets or always build new?

It checks first. In this build it scored its existing library against the design, decided nothing was close enough, and built all eight sections new.

What does it do about photographs of real people on a reference site?

It generates its own. Here it produced a founder portrait rather than reusing the real person’s photograph, and pointed the social links nowhere rather than at their actual accounts.

Start free for 30 days with 10,000 credits at wpos.ai. No card required, and nothing charges automatically. WPOS connects to any WordPress site, new or existing, on any host, and works alongside Gutenberg, Elementor, WooCommerce and Divi. Book a call with the founders at cal.com/algorismus/30min.