STEP 1
Define
Confirm the objective, affected files, architecture, and expected result.
Formationly Executive Operating System
FEOS Git & Release Workflow
The source-control, testing, rollback, release, and production-verification standards governing Formationly development.
Architecture Library • Version 1.0 • July 2026
Purpose of the Workflow
Every production change should be traceable, testable, and recoverable.
The FEOS Git and Release Workflow establishes how Formationly code and technical documentation move from development through validation, repository synchronization, Thinkific publication, production verification, and sprint closeout.
This workflow protects completed work, reduces accidental loss, supports rollback, and creates a reliable history of how the platform changed over time.
Current Repository Standard
Formationly development is standardized on the main branch.
PRIMARY BRANCH
main
All future approved Formationly development should be committed to main.
REMOTE REPOSITORY
GitHub
The private Formationly repository preserves the synchronized source history.
LOCAL DEVELOPMENT
VS Code
Code is edited, reviewed, staged, committed, and synchronized from the local repository.
PRODUCTION PLATFORM
Thinkific
Approved code is implemented and verified within the appropriate Thinkific theme or page.
Development Workflow
Every change should move through a controlled sequence.
STEP 2
Back Up
Confirm the current repository is synchronized and create a rollback point.
STEP 3
Build
Implement the approved code in the development environment.
STEP 4
Validate
Test desktop, mobile, links, workflows, and existing functionality.
STEP 5
Commit
Stage the correct files and create a clear, meaningful Git commit.
STEP 6
Synchronize
Push the approved commit to the remote GitHub repository.
STEP 7
Publish
Move the validated implementation into the approved production environment.
STEP 8
Verify
Confirm production behavior and document sprint closeout.
Pre-Change Checklist
Confirm the starting point before editing.
Confirm the active branch is main.
Confirm the local repository is synchronized with origin/main.
Confirm there are no unexplained or unrelated uncommitted changes.
Identify the exact theme, page, file, block, or component that will change.
Record or preserve the current working version before a substantial replacement.
Confirm the planned change aligns with approved FEOS architecture and engineering standards.
Commit Standards
A commit should describe a meaningful unit of completed work.
CLEAR
State what changed without vague wording.
FOCUSED
Avoid combining unrelated changes into one commit.
TRACEABLE
Reference the sprint, feature, page, or architecture volume when useful.
VERIFIED
Commit after validation, not before testing begins.
RECOMMENDED COMMIT FORMAT
Sprint 4.2: add FEOS navigation inventory
Fix mobile layout for Church Expansion Center
Add KCRM permissions architecture v1.0
Update Executive Headquarters progress panel
Fix mobile layout for Church Expansion Center
Add KCRM permissions architecture v1.0
Update Executive Headquarters progress panel
Staging Rules
Only intended files should enter the commit.
Review the Changes list before staging files.
Open changed files and confirm the edits belong to the current task.
Do not stage temporary files, copied backups, screenshots, credentials, or unrelated assets.
Separate unrelated work into different commits.
Confirm no required file was omitted before committing.
Repository Synchronization
A local commit is not fully protected until it is synchronized.
Commit the validated change locally.
Synchronize or push main to origin/main.
Confirm the synchronization completed without errors.
Verify the commit appears in the GitHub repository when the milestone is significant.
Confirm the local working tree is clean before ending the session.
Record unresolved synchronization issues before continuing development.
Rollback Strategy
Every major change should have a known recovery path.
Commit the last verified working version before beginning a significant redesign.
Document the files and Thinkific locations affected by the change.
Preserve the current published theme until the new development version is verified.
Revert to a known commit or restore the prior complete block when validation fails.
Do not attempt uncontrolled emergency fixes directly in production when a verified rollback is available.
After rollback, document the failure, recovery action, and next corrective step.
Thinkific Theme Workflow
Development and production should remain clearly separated.
DEVELOPMENT THEME
Build and Test
New navigation, dashboard, template, and theme changes should be implemented here first.
PREVIEW
Validate Experience
Review visual behavior, navigation, links, account functions, and responsive layouts.
PUBLISHED THEME
Production Baseline
Preserve the working production theme until the replacement is approved.
PUBLICATION
Controlled Release
Publish only after validation, synchronization, and rollback readiness.
Release Readiness Checklist
Publication requires more than visual approval.
Architecture and scope approved.
Correct files and code locations verified.
Desktop layout reviewed.
Mobile layout reviewed.
Navigation and links validated.
Native Thinkific functions preserved.
Accessibility and readability reviewed.
Regression checks completed.
Git commit created and synchronized.
Rollback point confirmed.
Production Verification
Publication is followed by real-user validation.
Open the published experience through the appropriate production URL.
Use the correct test account to verify partner-facing permissions and navigation.
Confirm desktop and mobile behavior in the published environment.
Verify critical links, account functions, embedded resources, and destination pages.
Record any production-only issue and determine whether to fix forward or roll back.
Release Classification
Release labels should reflect the significance of the change.
PATCH
Small Correction
Copy fixes, minor spacing, link correction, or isolated mobile repair.
MINOR RELEASE
New Capability
New page, component, resource library, workflow, or contained feature.
MAJOR RELEASE
Architectural Change
Navigation redesign, platform architecture change, KCRM launch, AI integration, or production-version milestone.
Git Tagging Guidance
Tags should mark meaningful, verified milestones.
A Git tag is not required for every commit. Tags should be created after major production releases, gold-master milestones, or architecture baselines that may need to be identified and restored later.
EXAMPLE
feos-v0.2
EXAMPLE
sprint-3.9-gold-master
RULE
Create the tag only after production verification and sprint closeout.
Emergency Change Process
Urgency does not eliminate traceability.
Confirm the issue materially affects production usability, access, security, or mission-critical functionality.
Preserve or identify the last known working version before making the correction.
Make the smallest responsible change needed to restore service.
Validate the correction immediately in the affected environment.
Commit, synchronize, document, and conduct follow-up review after stability is restored.
Sprint Release Closeout
Every sprint should end with a reliable development record.
Sprint objective and completed deliverables.
Important architecture and implementation decisions.
Files created, modified, moved, or retired.
Desktop, mobile, functional, and production validation status.
Commit description and synchronization confirmation.
Known issues, deferred items, and future considerations.
Recommended next sprint and starting action.
Definition of Released
A release is complete when all of the following are true.
The approved change is present in the intended production environment.
The production experience has been verified with the appropriate user account.
The source code is committed to main and synchronized with origin/main.
A rollback path remains available.
Architecture, sprint, technical, and release documentation has been updated where required.
The next development starting point is clearly documented.
Workflow Governance
The release process should evolve without losing control.
Changes to branch strategy should be approved and documented before use.
New deployment tools or automation should preserve human verification and rollback capability.
The workflow should be reviewed after failed releases, significant incidents, or major platform changes.
Repeated release problems should result in process improvement rather than repeated informal workarounds.
Build carefully. Preserve progress. Release with confidence.
The FEOS Git and Release Workflow ensures that Formationly development remains traceable, synchronized, recoverable, tested, and aligned with the long-term architecture of the platform.