Morpheus takes a request from the team channel, makes the change, reviews it, tests it and publishes it to staging. A named person reads it there and approves before anything reaches the public site.
This page reached the site the way it describes. It was dropped into a channel as a folder of Markdown and images, and a person approved it once.
A request is a sentence
The work starts where the team already talks. Anyone in the website channel can write to Morpheus in plain words: fix a heading, add a link to the footer, publish this article. An article arrives as a package, one Markdown file and the images it uses.
Morpheus sorts the request first. A change to the site becomes a tracked issue. An article goes to a workflow that unpacks it and checks that it has a title, a topic, alt text on every image and nothing the site cannot carry. A request it cannot act on gets a question back, in the same thread.
Morpheus does the work up to staging
From there the path is the same for every change.
- A pull request. Morpheus makes the change on a branch and opens a pull request under its own name.
- A review. It reads the change against the rules written in the site’s repository, and it looks at every image.
- The build. The site’s own checks build every page and test all of them.
- Staging. When the review is clean and the checks pass, Morpheus merges the change and publishes it to staging, where a person can read it as a visitor would.
If the review finds something, or a check fails, the change stays on its branch and the reason is posted where the request was made. Nothing is half-published.
Six checks on every change
The rules are written down once and run every time, so the standard does not depend on who is reviewing or how busy they are.
They cover what the site says about Morpheus, the claims it may make, the confidentiality of every client, the security policy, the structure each page needs, and the images.
The thread is the interface
The person who asked never leaves the conversation. The pull request, the review result and the staging link arrive as replies in the same thread, and each reply links to the record behind it.
The request to approve is posted to the channel itself, because one release can carry several changes. There is no new tool to learn and no hand-off to chase.
One decision stays with a person
Publishing to the public site is a separate authority, and Morpheus does not hold it. When a change is on staging, Morpheus verifies the pages, lists what changed and asks a named person to approve. Production then receives exactly the commit that was approved, and the approval is recorded with who gave it and when.
The reason is simple. The checks catch a page that says something the site may not say. They cannot catch something that is merely wrong, such as a stale figure, a misspelt name or a claim nobody verified. A person reading the page does.
This is the boundary we recommend for any workflow. Autonomy is earned per workflow, and preparation and external action carry different permissions. On this site, Morpheus has earned the path to staging. The last step is a person’s.
What it leaves behind
Every change leaves a trail that the next one starts from: the request, the issue, the pull request, the review, the build result and the approval. When someone asks why a page says what it says, the answer is a link to that record.
A note on status. This is our own site, run by our own team. It is customer zero evidence, a workflow running inside the business that built it. An independent customer result is a separate status, and this is not one.
Common questions
Can Morpheus publish to the public site on its own?
No. It publishes to staging. Production changes only after a named person approves the release, and only the approved commit is published.
What stops a bad change?
Three things, in order: Morpheus’s review against the site’s written rules, the site’s own build and checks, and the person who reads staging before approving. A failure at any of them stops the change and says why.
Does this need a content management system?
No. An article is a folder of Markdown and images in the site’s repository, so it is reviewed, versioned and checked like every other change.