4BR DEV OPERATING GUIDE • v1.9.3
How to use the 4BR build system.
A simple guide to what each DEV page does, how releases move forward, and how to review changes without risking production.
1 • MAIN DEV
Review the next website version
Use /dev/ to review the next 4BR homepage before anything is considered for production.
Open DEV →
2 • PROJECTS
Review the product portfolio
Use /dev-projects/ to see active 4BR-hosted software, AI, venture and infrastructure projects.
Open Projects →
3 • UPDATE CENTER
Check the installed DEV version
Use /dev-update/ to verify the current DEV version, build date and health status.
Open Update Center →
4 • PARTNER ROOM
Review partner readiness
Use /dev-partner-room/ for documentation status, procurement questions, brand rules and due-diligence links.
Open Partner Room →
THE RELEASE RULE
DEV first. Verify. Then decide.
BuildChanges go directly to DEV.
VerifyReview on phone and desktop.
ImproveFix issues and bump the DEV version.
Promote only when toldProduction stays frozen until explicit approval.
PAGE IDs VS RELEASE VERSIONS
The ID is the page. The version is the build.
WordPress Page IDA permanent database number for the page. Example: /dev/ = ID 2853. We can edit it repeatedly without changing that ID.
DEV Release VersionOur software-style checkpoint. Example: v1.8.8 → v1.8.10. It changes whenever we intentionally create a new reviewable build.
Think of the ID as the apartment number and the release version as the renovation number. The address stays the same; the build improves.
HOW TO GIVE GOOD FEEDBACK
Screenshots + one sentence are enough.
Point at what looks wrong and say what you want changed: “too much space,” “make this smaller,” “logo looks weak,” “keep this,” or “move it left.” The screenshot gives the visual context; the sentence gives the direction.
Important: Public 4BR pages are for business, software, projects and professional credibility. Personal/private learning work stays outside the public 4BR portfolio.
NEW DEV LAB • v0.1 • ISOLATED
Shul Schedule Lab
A test for turning scattered shul schedules into one clean Today / Week / Shabbat view. No changes to Torah Rocket or any shul website.
EXAMPLE • THE VILLAGE SHUL
Today • Shabbat
ParshaNitzavim–Vayeilech
Havdalah8:37 PM
Shabbat servicesource needed
WEEKDAY MORNING
Shacharit
Sunday8:00 AM
Mon–Fri7:00 AM
Rosh Chodesh may start 15 minutes earlier.
CONFLICT-SAFE MODE
Mincha + Maariv
The public page says these change weekly and points elsewhere. The engine must flag missing or stale sources instead of guessing.
Open source →
＋ Add week to calendar
✉ Email schedule
✓ Check source status
7-DAY BUILD DIRECTION
1 • Web + ShulCloud source adapters
2 • Freshness + conflict scoring
3 • Today / Week / Shabbat views
4 • ICS + email export
5 • RelayDesk-style reminders
6 • Torah Rocket integration contract only
Later • Shabbat dinner matchingPrivate opt-in hosts/guests, neighborhood, family makeup, dietary/accessibility preferences.
Later • Rabbi/shul governanceOptional approval, safety and escalation controls, separate from ordinary public schedule automation.
