jmiller
e738d31975
Universal: PR Check / Branch Policy (pull_request) Successful in 2s
Universal: PR Check / Validate PR (pull_request) Failing after 7s
Universal: PR Check / Secret Scan (pull_request) Successful in 9s
Joomla: Metadata Validation / Validate Joomla Metadata (pull_request) Successful in 40s
Universal: PR Check / Build RC Package (pull_request) Has been cancelled
Universal: PR Check / Report Issues (pull_request) Has been cancelled
Read package manifest via $adapter->getParent()->getManifest() to discover children dynamically instead of maintaining a hardcoded EXPECTED_EXTENSIONS array. Fail-open pattern wraps verification in try/catch. Only the success path (plugin enables, license warning) is gated; unconditional housekeeping (DLID restore) runs regardless. Claude-Session: https://claude.ai/code/session_01CwLGvFJPjoPTp9BEnSjtJf
Contributing to Moko Consulting Projects
Thank you for your interest in contributing! This guide explains our workflow, conventions, and how to get your changes merged.
Branching Workflow
We use a stability-gated branching model:
feature/* ──── PR ───→ dev
│ RC cut → rc → main
fix/* ───────── PR ────────────┘
- Create a branch from
dev:feature/<short-name>for new functionalityfix/<short-name>for bug fixeschore/<short-name>for maintenance
- Open a PR into
dev. - CI must pass before merge.
- Release cuts:
dev → rc → mainare handled by maintainers.
Never commit directly to
mainordev.
Version Policy
All repositories use the XX.YY.ZZ versioning scheme (two-digit segments):
XX-- major (breaking changes)YY-- minor (new features, backward-compatible)ZZ-- patch (bug fixes, security patches)
Stability suffixes may be appended during pre-release:
| Suffix | Meaning | Example |
|---|---|---|
-alpha.N |
Early testing | 06.01.00-alpha.1 |
-beta.N |
Feature complete | 06.01.00-beta.2 |
-rc.N |
Release candidate | 06.01.00-rc.1 |
| (none) | Stable release | 06.01.00 |
Auto-Bump
Version bumps are automated via the auto-bump workflow:
- Merges into
devtrigger a minor/patch bump. - The workflow updates all version references (manifests, changelog, etc.).
- Do not manually edit version numbers -- let the workflow handle it.
Commit Messages
We follow Conventional Commits:
<type>(<scope>): <short description>
<optional body>
<optional footer>
Types: feat, fix, docs, style, refactor, perf, test, chore, ci, build, revert
Pull Request Checklist
Before submitting a PR, ensure:
- Branch is based on latest
dev - Commit messages follow conventional commits
- CHANGELOG.md updated under
[Unreleased] - No
TODO.md,.claude/,.mcp.json, or minified files included - Code follows MokoStandards
- All CI checks pass
Code of Conduct
All contributors are expected to follow our Code of Conduct.
Questions?
Open a Question issue or contact us at hello@mokoconsulting.tech.