From a customer remark to a checked live site.
Someone writes. The team changes the site. A person says yes. The pages go live. A real browser opens them and sends a screenshot home. That is the delivery loop — the same story as website checks, told from the work, not from the admin screen.
- Remark
- Task
- GitHub
- Coding agent
- Approve
- Publish
- Browser check
- Pass
- Fail
How it looks
A remark becomes a task. The change goes through GitHub — or a coding agent helps write it. A person approves. The site is published. A browser checks the pages. Pass or fail comes back with a screenshot.
MCP Fabric / delivery loop
- Remark
- Task
- GitHub
- Coding agent
- Approve
- Publish
- Browser check
- Pass
- Fail
The delivery loop
Follow the path once: from the first message to the picture of the live page.
Someone writes
Chat, mail or a form starts the work. The remark belongs to a website, not to a pile of tickets.
See moreA task for that site
The work stays on one website. The next remark does not wander off to another site by accident.
See moreHelp writing the change
A coding agent can prepare the edit. A person still decides what goes live.
See moreA person says yes
Publishing waits for a human. The browser check then looks — it does not rewrite the server.
See moreThe site goes live
The site is published on your server. Then the check looks at the real pages, not a mock.
See moreThe image that belongs to the site
If the site ships as a container, the login for that registry travels with the publish step — not pasted into chat.
See moreA browser opens the live pages
It opens the paths you chose, clicks, fills ordinary fields, and takes a screenshot. Like a careful visitor, not a robot on the whole internet.
See moreThe result comes home
The team sees pass or fail and the picture. You can tell the customer without reading a developer log.
See moreThe next remark stays here
The next note keeps the same website. The loop does not jump to another project.
See moreWho is in the story
The people around a live website — including a guesthouse site like Penzion Pod Farou. The lodging booking chat there is a different story.
The person who wrote in
A guest, a client, someone on the site. They should feel that the change was looked at — not that a ticket vanished.
The person who runs the site
Starts the check, watches it, and knows when a page failed. Nothing passes in silence.
The person who sets the site up
Names the website, confirms the address, and connects GitHub or the server when you want the full loop.
The person in the editor
Can run the same check for this website from the tools they already use.
See moreTwo ways to use it
Start with a check of the live pages. Or run the whole delivery: code, approval, publish, then the same browser look.
Just look at the live site
Name the site, choose the pages, run the check. Enough when the change already went out another way.
The full loop
Add GitHub, the server, and publish — then the same browser look, after a person approves.
Explore more
The lodging booking chat at Penzion Pod Farou is a different story. This page is what happens after you change the website.
Website checks
A guest or a colleague writes. The team changes the website. Someone says yes. The pages go live. Then a real browser opens them, walks the path a visitor would, and brings a screenshot back to the team. That is website checks: the last look before you trust the change.
GitHub
The change for this website lives in GitHub — picked from a list, then published after a person says yes.
Ansible
Publishing the site from the same project, then the browser looks at what actually went live.
SSH
Reach the server the pages run on — Linux or Windows — before the browser opens them.
MCP
Run the same website check from the editor you already use.
Automated processes
The loop is a process: remark, change, approve, publish, check.
Interactive chat
A guest or a colleague writes. That is often how the loop starts.
Ready to move beyond the chatbot?
Build AI that understands your business, works with your knowledge, follows your processes and can actually finish the job. You decide which actions are allowed, when a person must step in and how much AI usage your organization can consume.