Open the live site in a browser — and send the picture home.
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.
- 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
One story, from the first remark to the screenshot 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 moreWhat the visitor actually gets
Not a lab report. A named site, the pages you care about, a short walk through them, and a picture of how it went.
A website, not a vague profile
Each project is one site: its address, its pages, its steps. Another site is another project.
Only the pages you chose
The browser stays on the addresses you allowed. It does not wander.
A short walk through the site
Open, click, fill, look for what should be there, take a picture. The path is yours to write.
A picture with the answer
Pass or fail arrives with a screenshot the team can actually look at.
Two 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.
How a website project is set up
A short guided path. You name the site, choose the pages, and connect the pieces you already use.
Name the site
Give the project a name and choose whether you only check pages, or also publish them.
The address and the walk
The public address, the pages that may be opened, and a first walk across the homepage.
The server
Reach Linux over SSH, or Windows the Windows way — whichever the site actually runs on.
See moreHow it is published
Choose how the site is rolled out. Secrets stay in the vault, not on the project card.
See moreLook once, then go
A last look at the address and the connections. Then the project is ready to run.
GitHub on the same project
The change lives in the repositories that belong to this website — picked from a list, not guessed.
Pick repositories from a list
Search the repositories you already have. You do not type owner/repo from memory.
See moreThe GitHub App you installed
Choose the installation from a list, then the repositories it can see.
See moreOnly this website’s repositories
Changes stay in the repos tied to this project. Another company’s connection does not leak in.
See morePublishing the site
The same project can reach the server. A person approves before anything is written. Then the browser looks at what actually went live.
Publish from the project
The playbook and the connection belong to this website. A person still says yes before production.
See moreA look at the host
A command can confirm the machine is up. The browser check is still the look at the pages.
See moreWindows when the site is Windows
Windows remoting is there when the server is Windows — not mixed into a Linux guesthouse path.
See moreThe same check from an editor
From the tools you already work in, you run the check for that website — not a free roam across the internet.
The same check in your editor
The published tool is the website check for that project. The run is recorded like any other run.
See moreThis site, not any URL
You point at the project. A free address on the internet is not a check.
Explore more
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.