Debug one boundary at a time: source revision, runtime dependencies, configuration, route resolution, model/filter behavior, then database or template output. Keep each test small enough to explain why it passed or failed.
Confirm the source you are running
Record the repository URL, branch and git rev-parse HEAD. Check whether your application loads a local checkout or an installed package. In PHP, the included sample uses a local Composer path repository; editing a different checkout will not necessarily change the code that runs. In Perl, distinguish the current main branch from the legacy master branch.
Separate dependency failures from application failures
Run the documented framework tests before interpreting errors in generated application code. A missing PHP extension, CPAN module, Java JAR or Go toolchain is an environment problem first. Record skipped database tests separately from passing tests. Do not point a test harness at a production database.
Inspect the configuration contract
- Check the entry path, role, response tag and component against the project's configuration.
- Confirm that a component declares the requested action and the expected table and key names.
- Verify that the implementation can load the model and filter: Go factories, PHP namespaces, Perl module paths and Java constructors are different mechanisms.
- For templates, inspect the configured template root and the role/component/action path expected by the implementation.
Check a database error with a disposable example
Confirm the driver, host, database name and schema outside the failing business workflow. Then reproduce a single operation with synthetic data. Avoid printing a connection string containing a password. Historical schema examples may differ from the current sample's seed files; compare them before changing application code.
Check roles and mutating requests
Exercise both authorized and unauthorized requests. Test missing or invalid session data, expected CSRF rejection, input validation and resource boundaries. The repository's feature list is a starting point; your configuration and custom methods determine the application's actual behavior.
When asking for help
Share the smallest non-sensitive reproduction, exact revision, command and error message. Say which framework tests passed, which failed and which you did not run. See Community for the verified issue trackers.