What is forge
Forge provides the submission path between a ChAoS developer's work and the review processes of the ChAoS MVC ecosystem.
It is intended for both developers who have already completed ChAoS certification and developers who are beginning to work with ChAoS MVC and have not yet become certified.
Development does not begin with certification. It begins with learning the framework, building something useful, documenting the work, and demonstrating that the developer understands the standards under which ChAoS MVC operates.
Forge provides a place for that work to enter the ChAoS review process.
Forge sits between development and formal review.
A developer creates a project using ChAoS MVC standards and submits the resulting work through Forge under the appropriate submission type.
Forge does not replace development, testing, documentation, or human review. It provides the structured submission path through which completed work can be presented for those processes.
The general relationship is:
The developer remains responsible for the work being submitted.
Forge is useful to both certified and non-certified ChAoS developers.
You do not need to already be a certified ChAoS developer to begin developing with ChAoS MVC.
In fact, Forge is a good place to begin the certification process.
A developer seeking certification can learn the ChAoS MVC development model, construct a working project, test and document that project, and submit the work through Forge for certification review.
This provides something concrete for review: actual work produced using the framework.
Certification is emphasized within the ChAoS MVC ecosystem because it provides a means of demonstrating that a developer understands the framework, its development standards, its authority boundaries, and the responsibilities associated with producing work for the ecosystem.
Forge gives a developing ChAoS developer a path toward demonstrating that understanding.
Certified ChAoS developers may use Forge to submit new work, revisions, and work intended for ChAoS ecosystem distribution.
Certification does not eliminate the review process.
A certified developer remains responsible for developing, testing, documenting, and submitting work according to the applicable ChAoS MVC standards.
Certification establishes the developer's recognized relationship with the ChAoS development process; it does not turn every future submission into automatically accepted work.
Forge currently recognizes three primary submission types.
Use Certification when submitting work for ChAoS certification review.
This is the appropriate submission path for a developer using their work as part of the certification process.
The submitted project should represent the developer's own understanding and implementation of ChAoS MVC development practices.
A developer considering ChAoS certification is encouraged to begin by learning the framework, developing within its established boundaries, and producing work that can be examined through Forge.
Use Marketplace for work intended for future ChAoS ecosystem distribution.
Marketplace submission identifies the developer's intention for the project to become distributable within the ChAoS ecosystem.
Submission does not itself mean that the project has been approved, certified, published, or distributed.
It places the work into the appropriate review path.
Use Revision when submitting an updated revision of previously developed work.
Software changes over time. Bugs are corrected, functionality is refined, documentation improves, and new capabilities may be introduced.
A revision allows those changes to be submitted while maintaining the relationship between the new work and the project that preceded it.
Forge should receive work that is ready to be reviewed.
Before submitting a project, the developer should examine the work as if another developer were going to receive it without explanation.
At minimum, ask:
Do not describe untested behavior as tested behavior.
Do not describe an implementation as confirmed merely because the code appears correct.
A reviewer should be able to distinguish between what was designed, what was implemented, what was tested, and what was actually confirmed.
ChAoS MVC follows a simple development principle:
Application-specific functionality belongs outside the protected ChAoS MVC Core.
A developer working on a module owns the module's application behavior. The module does not acquire authority over Core simply because changing Core might make a particular implementation easier.
When an established Core capability is insufficient, the correct response is to identify the missing framework capability rather than silently modifying, bypassing, duplicating, or replacing Core behavior.
Understanding this boundary is particularly important for developers seeking ChAoS certification.
Certification is not merely a demonstration that someone can make PHP execute.
It demonstrates the developer's ability to work within the architecture and development standards of ChAoS MVC.
Documentation is part of the work.
A reviewer should not have to reverse-engineer a project simply to discover what the developer intended it to do.
Documentation should accurately describe the project, its purpose, its current development state, and any important lifecycle or operational requirements.
For ChAoS MVC modules, the project's
Good documentation also protects the developer.
Months after a project was written, documentation provides the historical trail needed to understand why something exists, what changed, and what state the project had reached.
Implementation and demonstrated behavior are different things.
A feature may be:
Those states should not be treated as interchangeable.
Forge submissions should describe testing accurately.
If something has not been tested, say that it has not been tested.
If a test failed, preserve that information and correct the implementation before representing the behavior as confirmed.
ChAoS development favors evidence over assumption.
Developers interested in contributing to the ChAoS MVC ecosystem are strongly encouraged to pursue certification.
Certification creates a common development baseline between the developer and the ecosystem.
It demonstrates familiarity with the framework, its development practices, its security expectations, its architectural boundaries, and the responsibility that accompanies producing work intended for other people to use.
You do not have to wait until you are certified to begin learning.
Build.
Test.
Document.
Learn why ChAoS MVC behaves the way it does.
Then use Forge to submit that work for certification review.
For a developer wondering where to begin, Forge provides a practical answer:
Forge should not be confused with the development process itself.
Forge does not make incomplete work complete.
It does not replace testing.
It does not replace documentation.
It does not automatically certify a developer.
It does not automatically approve a project for ecosystem distribution.
It does not transform a submission into accepted work merely because the developer submitting it is already certified.
Forge provides the submission path.
The work provides the evidence.
The applicable review process determines what happens next.
For a new developer:
For an established certified developer:
The machinery is intentionally straightforward.
The important part is not making submission complicated.
The important part is ensuring that the work entering the ChAoS MVC ecosystem can be identified, examined, reviewed, and understood.
If you are new to ChAoS MVC, you do not need to know everything before you begin.
Learn the framework.
Build within its established boundaries.
Keep records of what you change.
Test what you claim works.
Document what you build.
When you have work ready to demonstrate, submit it through Forge.
Certification is strongly encouraged because ChAoS MVC is intended to provide a predictable development ecosystem in which developers and users can understand the standards behind the software they receive.
Forge is one of the places where that relationship begins.
Build it. Test it. Document it. Forge it.
It is intended for both developers who have already completed ChAoS certification and developers who are beginning to work with ChAoS MVC and have not yet become certified.
Development does not begin with certification. It begins with learning the framework, building something useful, documenting the work, and demonstrating that the developer understands the standards under which ChAoS MVC operates.
Forge provides a place for that work to enter the ChAoS review process.
The Role of Forge
Forge sits between development and formal review.
A developer creates a project using ChAoS MVC standards and submits the resulting work through Forge under the appropriate submission type.
Forge does not replace development, testing, documentation, or human review. It provides the structured submission path through which completed work can be presented for those processes.
The general relationship is:
Develop
↓
Test
↓
Document
↓
Submit through Forge
↓
Review
↓
Certification or Ecosystem Process
The developer remains responsible for the work being submitted.
Who May Use Forge?
Forge is useful to both certified and non-certified ChAoS developers.
Non-Certified Developers
You do not need to already be a certified ChAoS developer to begin developing with ChAoS MVC.
In fact, Forge is a good place to begin the certification process.
A developer seeking certification can learn the ChAoS MVC development model, construct a working project, test and document that project, and submit the work through Forge for certification review.
This provides something concrete for review: actual work produced using the framework.
Certification is emphasized within the ChAoS MVC ecosystem because it provides a means of demonstrating that a developer understands the framework, its development standards, its authority boundaries, and the responsibilities associated with producing work for the ecosystem.
Forge gives a developing ChAoS developer a path toward demonstrating that understanding.
Certified Developers
Certified ChAoS developers may use Forge to submit new work, revisions, and work intended for ChAoS ecosystem distribution.
Certification does not eliminate the review process.
A certified developer remains responsible for developing, testing, documenting, and submitting work according to the applicable ChAoS MVC standards.
Certification establishes the developer's recognized relationship with the ChAoS development process; it does not turn every future submission into automatically accepted work.
Submission Types
Forge currently recognizes three primary submission types.
Certification
Use Certification when submitting work for ChAoS certification review.
This is the appropriate submission path for a developer using their work as part of the certification process.
The submitted project should represent the developer's own understanding and implementation of ChAoS MVC development practices.
A developer considering ChAoS certification is encouraged to begin by learning the framework, developing within its established boundaries, and producing work that can be examined through Forge.
Marketplace
Use Marketplace for work intended for future ChAoS ecosystem distribution.
Marketplace submission identifies the developer's intention for the project to become distributable within the ChAoS ecosystem.
Submission does not itself mean that the project has been approved, certified, published, or distributed.
It places the work into the appropriate review path.
Revision
Use Revision when submitting an updated revision of previously developed work.
Software changes over time. Bugs are corrected, functionality is refined, documentation improves, and new capabilities may be introduced.
A revision allows those changes to be submitted while maintaining the relationship between the new work and the project that preceded it.
Before You Submit
Forge should receive work that is ready to be reviewed.
Before submitting a project, the developer should examine the work as if another developer were going to receive it without explanation.
At minimum, ask:
- Does the project operate as intended?
- Has the work actually been tested?
- Does the project follow the applicable ChAoS MVC development standards?
- Is its purpose understandable?
- Is the project documented?
- Are its files and responsibilities organized appropriately?
- Are known limitations identified rather than hidden?
- Does the submission accurately represent the state of the work?
Do not describe untested behavior as tested behavior.
Do not describe an implementation as confirmed merely because the code appears correct.
A reviewer should be able to distinguish between what was designed, what was implemented, what was tested, and what was actually confirmed.
ChAoS MVC Development Boundaries
ChAoS MVC follows a simple development principle:
Secure the Core. Grow outwards.
Application-specific functionality belongs outside the protected ChAoS MVC Core.
A developer working on a module owns the module's application behavior. The module does not acquire authority over Core simply because changing Core might make a particular implementation easier.
When an established Core capability is insufficient, the correct response is to identify the missing framework capability rather than silently modifying, bypassing, duplicating, or replacing Core behavior.
Understanding this boundary is particularly important for developers seeking ChAoS certification.
Certification is not merely a demonstration that someone can make PHP execute.
It demonstrates the developer's ability to work within the architecture and development standards of ChAoS MVC.
Documentation Matters
Documentation is part of the work.
A reviewer should not have to reverse-engineer a project simply to discover what the developer intended it to do.
Documentation should accurately describe the project, its purpose, its current development state, and any important lifecycle or operational requirements.
For ChAoS MVC modules, the project's
docs/CHANGELOG.md serves as the module lifecycle record and should reflect the module's current development state.Good documentation also protects the developer.
Months after a project was written, documentation provides the historical trail needed to understand why something exists, what changed, and what state the project had reached.
Testing Matters
Implementation and demonstrated behavior are different things.
A feature may be:
- Designed.
- Implemented.
- Tested.
- Confirmed.
Those states should not be treated as interchangeable.
Forge submissions should describe testing accurately.
If something has not been tested, say that it has not been tested.
If a test failed, preserve that information and correct the implementation before representing the behavior as confirmed.
ChAoS development favors evidence over assumption.
Certification as a Starting Point
Developers interested in contributing to the ChAoS MVC ecosystem are strongly encouraged to pursue certification.
Certification creates a common development baseline between the developer and the ecosystem.
It demonstrates familiarity with the framework, its development practices, its security expectations, its architectural boundaries, and the responsibility that accompanies producing work intended for other people to use.
You do not have to wait until you are certified to begin learning.
Build.
Test.
Document.
Learn why ChAoS MVC behaves the way it does.
Then use Forge to submit that work for certification review.
For a developer wondering where to begin, Forge provides a practical answer:
Begin with the work. Demonstrate what you understand. Submit the evidence.
What Forge Does Not Do
Forge should not be confused with the development process itself.
Forge does not make incomplete work complete.
It does not replace testing.
It does not replace documentation.
It does not automatically certify a developer.
It does not automatically approve a project for ecosystem distribution.
It does not transform a submission into accepted work merely because the developer submitting it is already certified.
Forge provides the submission path.
The work provides the evidence.
The applicable review process determines what happens next.
A Simple Forge Workflow
For a new developer:
Learn ChAoS MVC
↓
Develop a Project
↓
Test the Project
↓
Document the Project
↓
Submit to Forge
↓
Certification Review
For an established certified developer:
Develop or Revise
↓
Test
↓
Document
↓
Submit to Forge
↓
Applicable Review
The machinery is intentionally straightforward.
The important part is not making submission complicated.
The important part is ensuring that the work entering the ChAoS MVC ecosystem can be identified, examined, reviewed, and understood.
Begin at the Forge
If you are new to ChAoS MVC, you do not need to know everything before you begin.
Learn the framework.
Build within its established boundaries.
Keep records of what you change.
Test what you claim works.
Document what you build.
When you have work ready to demonstrate, submit it through Forge.
Certification is strongly encouraged because ChAoS MVC is intended to provide a predictable development ecosystem in which developers and users can understand the standards behind the software they receive.
Forge is one of the places where that relationship begins.
Build it. Test it. Document it. Forge it.