shipley-integrations

site/

The files in here are live pages on https://shipleyfarmsbeef.com/?utm_source=github&utm_medium=repo&utm_campaign=shipley-integrations&utm_content=site-readme.

This is the part most open source projects cannot offer you. A change you make here does not go into a demo or a sandbox. When it is merged, it appears on a working farm’s actual website, the one customers buy beef from.

File	Live at
helloworld.html	https://shipleyfarmsbeef.com/helloworld?utm_source=github&utm_medium=repo&utm_campaign=shipley-integrations&utm_content=site-readme

How a change gets from here to the live site

1. You edit the file and open a pull request.
2. CI checks the markup is well formed and that nothing dangerous slipped in.
3. A maintainer reviews it.
4. On merge, an operator runs the publisher script against production.
5. It is live.

Step 4 is a human on purpose. A member of our team reviews and publishes every change before it reaches a customer. That is not distrust of you; it is the same rule we apply to ourselves, and it is why nothing in this repository can reach the live site on its own.

What you can change here

Wording, structure, links, headings, accessibility improvements, and fixing things that are plainly wrong. If you want to restructure a page substantially, open an issue first so you do not spend an evening on something we then have to argue about.

What will get a pull request declined

• Anything that can run code, fetch from another host, cover the page, or redirect a visitor. These pages are served on the same domain as our checkout, so markup here is not a document, it is code running where our customers’ sessions live. tools/sitegate.py is the exact rule and it explains itself: the tags and attributes these pages may use are an allowlist, URLs are parsed and their host matched exactly, and style attributes may not carry url(...) or a position declaration. CI runs it on your pull request, an operator runs the real gate again before publishing, and the two are checked against a shared attack corpus. Run it yourself before you push: python3 tools/validate_site.py.
• Tracking pixels or third party embeds of any kind.
• Removing the security or rate limiting notices. Those are there for a real reason.
• Inventing facts about the farm. If you are not sure whether something is true, ask in the pull request rather than guessing. We will tell you.

House style

• Real headings in order (h1, then h2, then h3). Screen readers navigate by them.
• Text that makes sense without CSS or JavaScript.
• Plain language. Our readers include cattle farmers, chefs, and fourteen year olds writing their first pull request.
• Brand red is #A82024. It passes AAA contrast on white. Please do not introduce another red.
• No em dashes. House preference, applied consistently.

Yes, the typo is on purpose

helloworld.html contains exactly one deliberate spelling mistake, as a first task for someone who has never sent a pull request before. If you find it, fix it, and it is still there in main, that fix is yours to make.

If you are reading this because you already fixed it: thank you, and please leave the invitation paragraph itself intact so the next person still has a way in.

It is a relay. When a fix is merged a maintainer plants a fresh one somewhere else on the page, and the person who found the old one gets a row in the chain in SEEDED.md. That file is also the ledger CI reads: main goes red while a seed has been fixed and not replaced, so the relay cannot quietly stop because everybody was busy. The word itself is stored there as a hash rather than in plain text, for the obvious reason.

Maintainers: tools/plant_seed.py does the whole handover, and refuses to plant the same misspelling that was just fixed.

This site is open source. Improve this page.