added unity files
All checks were successful
Code Documentation / code-docs (push) Successful in 6s
Project Report / project-report (push) Successful in 4s
Validate Code / validate (push) Successful in 3s

This commit is contained in:
Frank Harris 2026-06-15 12:03:33 -05:00
parent 9042333f51
commit 28c15035a4
62 changed files with 3873 additions and 270 deletions

43
docs/ARCHITECTURE.md Normal file
View file

@ -0,0 +1,43 @@
# Architecture
## Overview
This repository uses Forgejo Actions on a `linux-dev` runner to validate customer code and generate project analysis reports.
Green workflow:
Automation completed and reports were generated.
Red workflow:
Automation itself failed, crashed, or required reports were not produced.
## Components
- Forgejo workflows
- `linux-dev` runner
- `tools/validate-code.sh`
- `tools/project-report.sh`
- customer source files
- generated markdown reports
- future deployment automation, kept separate from debugging automation
## Text Diagram
```text
Customer Push / Pull Request
|
v
Forgejo Workflow
|
+--> validate.yml --> tools/validate-code.sh --> reports/errors.md
|
+--> project-report.yml --> tools/validate-code.sh
tools/project-report.sh
--> reports/*.md
|
v
Forgejo Logs print summaries and report excerpts
```
## Future Direction
Later deployment automation may choose to block releases when errors are found. That is intentionally separate from the current DevPlus1 debugging behavior.

View file

@ -1,108 +1,113 @@
# Automation
## Purpose
## Intentional Behavior
This repository includes two Forgejo Actions workflows for reusable customer-project automation:
This repository is for customer debugging projects.
- `validate.yml`: runs repository validation on push and pull request.
- `project-report.yml`: generates best-effort project analysis reports on push and pull request.
Customers are expected to upload broken code.
Because of that:
- Green workflow means automation completed.
- Red workflow means automation failed.
- Customer code errors are listed in `reports/errors.md`.
- Broken customer code does not fail the workflow red.
This behavior is intentional for DevPlus1.
## Workflows
### `validate.yml`
- runs on `push`
- runs on `pull_request`
- uses the `linux-dev` runner label
- checks out the repository
- runs `tools/validate-code.sh`
- fails when validation finds real errors
- Runs on `push`
- Runs on `pull_request`
- Uses runner label `linux-dev`
- Runs `tools/validate-code.sh`
- Prints `reports/errors.md` into Forgejo logs
- Fails only if the validation script crashes or `reports/errors.md` is missing
### `project-report.yml`
- runs on `push`
- runs on `pull_request`
- uses the `linux-dev` runner label
- checks out the repository
- runs `tools/project-report.sh`
- regenerates reports in `reports/`
- does not fail because analysis finds issues or uncertainty
- only fails if the script itself crashes
- Runs on `push`
- Runs on `pull_request`
- Uses runner label `linux-dev`
- Runs `tools/validate-code.sh`
- Runs `tools/project-report.sh`
- Prints report summaries into Forgejo logs
- Fails only if report generation crashes or required report files are missing
### `code-docs.yml`
- Runs on `push`
- Runs on `pull_request`
- Uses runner label `linux-dev`
- Runs `tools/generate-code-docs.sh`
- Prints code documentation summary output into Forgejo logs
- Fails only if the documentation script crashes or required code documentation reports are missing
## Scripts
### `tools/validate-code.sh`
This script recursively scans the repository while excluding common generated or dependency folders such as:
- `.git`
- `.forgejo`
- `node_modules`
- `vendor`
- `Library`
- `Temp`
- `Logs`
- `obj`
- `bin`
When the necessary tools are installed, it validates:
- PHP with `php -l`
- Python with `python3 -m py_compile`
- Ruby with `ruby -c`
- Perl with `perl -c`
- Shell with `bash -n`
- JavaScript with `node --check`
- JSON with `jq`
- YAML with `yamllint`
- HTML with `tidy`
- C# with `dotnet build`
- C/C++ CMake projects with `cmake` configure validation
It writes `reports/errors.md` with:
- validation summary
- files checked
- warnings
- errors
- detailed per-file results
- Recursively scans the repository
- Excludes common dependency and generated directories
- Validates supported files when tools are installed
- Always writes `reports/errors.md`
- Always prints a terminal summary
- Exits `0` even when customer code errors are found
- Exits non-zero only for automation/report generation failure
### `tools/project-report.sh`
This script generates:
- Generates project analysis reports
- Reads customer code error status when available
- Writes summary and generated-file tracking reports
- Exits non-zero only if the script itself cannot generate required outputs
### `tools/generate-code-docs.sh`
- Reads customer source files without modifying them
- Generates best-effort API, file-purpose, Unity lifecycle, and call-map reports
- Uses regex-based extraction and cautious wording
- Exits non-zero only if report generation fails
## Generated Report Files
- `reports/errors.md`
- `reports/project-flow.md`
- `reports/file-summary.md`
- `reports/languages.md`
- `reports/summary.md`
- `reports/generated-files.md`
- `reports/customer-code-status.txt`
- `reports/api-reference.md`
- `reports/file-purpose.md`
- `reports/unity-scripts.md`
- `reports/call-map.md`
- `reports/code-docs-summary.md`
It performs best-effort analysis for:
## Validation Sample Files
- language counts
- likely entry points
- possible startup files
- framework detection
- database detection
- environment files
- config files
- Docker-related files
- probable application flow
The repository includes intentional validator fixtures under `tests/validation-samples/`.
The wording is intentionally cautious. It does not claim certainty.
These files exist to prove:
## Reuse In Future Customer Repositories
- valid samples are accepted
- broken samples are reported
- broken customer code does not force the workflow red
To reuse this automation in another repository:
## Extending The System
1. Copy `.forgejo/workflows/validate.yml`
2. Copy `.forgejo/workflows/project-report.yml`
3. Copy `tools/validate-code.sh`
4. Copy `tools/project-report.sh`
5. Create `reports/.gitkeep`
6. Keep the exclude list if the repository includes generated or dependency folders
7. Review language and framework detection rules for project-specific needs
To add more validators later:
## Notes
1. Update `tools/validate-code.sh`
2. Document the validator in `docs/VALIDATORS.md`
3. Update `docs/AUTOMATION.md` and `docs/WORKFLOWS.md` if workflow behavior changes
4. Update `docs/CODEX_INSTRUCTIONS.md`
- Reports are regenerated on every run.
- Validation skips checks gracefully when required tools are not installed.
- The automation is additive and does not modify customer source files.
To add more code documentation extraction later:
1. Update `tools/generate-code-docs.sh`
2. Document new reports in `docs/REPORTS.md`
3. Document workflow changes in `docs/WORKFLOWS.md`
4. Update `docs/CODEX_INSTRUCTIONS.md`

View file

@ -0,0 +1,52 @@
# Codex Instructions
## Repository Purpose
This repository is the master template for Runlevel Systems DevPlus1 customer debugging and analysis projects.
## Expected Workflow
1. Read this documentation set first.
2. Run or inspect validation automation.
3. Review generated reports before making assumptions about customer code.
4. Treat customer code errors as reportable debugging inputs, not workflow failures.
## Expected Reports
- `reports/errors.md`
- `reports/project-flow.md`
- `reports/file-summary.md`
- `reports/languages.md`
- `reports/summary.md`
- `reports/generated-files.md`
- `reports/api-reference.md`
- `reports/file-purpose.md`
- `reports/unity-scripts.md`
- `reports/call-map.md`
- `reports/code-docs-summary.md`
## Expected Validation Behavior
- Green workflow means automation completed.
- Red workflow means automation failed.
- Customer code errors do not fail workflows.
- Customer code errors are reported in `reports/errors.md`.
- Reports should always be generated whenever possible.
- New validators should be added through `VALIDATORS.md`.
- New workflows should be documented in `WORKFLOWS.md`.
- Code documentation reports are generated by `tools/generate-code-docs.sh`.
- The code documentation generator is read-only against customer source files.
## Recommended File Reading Order For Codex
1. `docs/CODEX_INSTRUCTIONS.md`
2. `docs/README.md`
3. `docs/ARCHITECTURE.md`
4. `docs/WORKFLOWS.md`
5. `docs/REPORTS.md`
6. `docs/VALIDATORS.md`
7. `docs/REPOSITORY_MAP.md`
## Maintenance Rule
Update this file whenever automation behavior changes. These docs are authoritative and should stay current as the repository evolves.

43
docs/README.md Normal file
View file

@ -0,0 +1,43 @@
# Customer-Test Documentation
## Purpose of Repository
This repository is the master template for Runlevel Systems DevPlus1 customer debugging and analysis projects.
Customers are expected to upload code that may already be broken. The repository automation is designed to inspect that code, generate reports, and keep the workflows green when the automation itself succeeds.
## Purpose of DevPlus1 Customer Debugging
DevPlus1 customer debugging projects need fast, repeatable automation that:
- validates customer code where supported
- reports errors clearly
- analyzes project structure
- generates documentation-friendly markdown output
- does not confuse customer code problems with automation failures
## Repository Goals
- Make Forgejo Actions useful for debugging projects.
- Generate reports on every push and pull request when possible.
- Keep customer code errors visible in logs and markdown.
- Reserve red workflows for automation failures only.
- Provide documentation that future Codex sessions can read first.
## High-Level Workflow
1. Customer code is pushed to the repository.
2. `validate.yml` runs validation and writes `reports/errors.md`.
3. `project-report.yml` generates structure and flow reports in `reports/`.
4. Forgejo logs print report summaries directly.
5. A developer or future Codex session reviews the reports before deeper work.
## Documentation Index
- [CODEX_INSTRUCTIONS.md](./CODEX_INSTRUCTIONS.md)
- [ARCHITECTURE.md](./ARCHITECTURE.md)
- [WORKFLOWS.md](./WORKFLOWS.md)
- [REPORTS.md](./REPORTS.md)
- [VALIDATORS.md](./VALIDATORS.md)
- [REPOSITORY_MAP.md](./REPOSITORY_MAP.md)
- [AUTOMATION.md](./AUTOMATION.md)

73
docs/REPORTS.md Normal file
View file

@ -0,0 +1,73 @@
# Reports
## `reports/errors.md`
- Purpose: validation report for customer code and repository files
- Generated by: `tools/validate-code.sh`
- Typical contents: validation summary, files checked, warnings, errors, detailed per-file results
## `reports/project-flow.md`
- Purpose: best-effort project flow analysis
- Generated by: `tools/project-report.sh`
- Typical contents: likely entry point, possible startup files, detected frameworks, detected databases, probable application flow
## `reports/file-summary.md`
- Purpose: repository structure summary
- Generated by: `tools/project-report.sh`
- Typical contents: top-level folders, file counts by type, largest source directories
## `reports/languages.md`
- Purpose: language inventory
- Generated by: `tools/project-report.sh`
- Typical contents: counts for supported source and config languages
## `reports/summary.md`
- Purpose: single high-level automation snapshot
- Generated by: `tools/project-report.sh`
- Typical contents: generation time, repo name, branch, commit, generated files, customer code status, overview, language counts, likely entry points, frameworks, databases
## `reports/generated-files.md`
- Purpose: explicit list of report files created or updated during the run
- Generated by: both scripts
- Typical contents: markdown list of generated report files
## `reports/customer-code-status.txt`
- Purpose: single-line machine-readable customer code status
- Generated by: `tools/validate-code.sh`
- Typical contents: `CUSTOMER CODE ERRORS FOUND` or `NO CUSTOMER CODE ERRORS FOUND`
## `reports/api-reference.md`
- Purpose: at-a-glance reference of detected functions, methods, classes, and public APIs
- Generated by: `tools/generate-code-docs.sh`
- Typical contents: file path, language, class, function/method name, parameters, return type, visibility, static/async markers, guessed purpose, parsing notes
## `reports/file-purpose.md`
- Purpose: file-by-file summary for quick customer project review
- Generated by: `tools/generate-code-docs.sh`
- Typical contents: file path, language, line count, detected classes, detected functions, imports/includes, possible purpose, likely role notes
## `reports/unity-scripts.md`
- Purpose: Unity-specific lifecycle and script role map
- Generated by: `tools/generate-code-docs.sh`
- Typical contents: MonoBehaviour/ScriptableObject classes, lifecycle methods, serialized/public fields, public methods, Unity API usage, possible script role
## `reports/call-map.md`
- Purpose: best-effort static map of possible entry points, imports/includes, function definitions, call references, and relationships
- Generated by: `tools/generate-code-docs.sh`
- Typical contents: possible entry points, detected imports, function definitions, possible calls, relationship guesses, limitations
## `reports/code-docs-summary.md`
- Purpose: concise summary of the code documentation generation run
- Generated by: `tools/generate-code-docs.sh`
- Typical contents: reports written, source files scanned, functions/methods detected, classes detected, Unity scripts detected, possible entry points, detected code types

36
docs/REPOSITORY_MAP.md Normal file
View file

@ -0,0 +1,36 @@
# Repository Map
## Top-Level Structure
- `.forgejo/workflows/`
Purpose: Forgejo Actions workflow definitions
- `tools/`
Purpose: validation and report-generation scripts
- `reports/`
Purpose: generated markdown and status outputs
- `tests/validation-samples/`
Purpose: intentional valid and broken sample files for validator behavior
- `docs/`
Purpose: authoritative repository documentation
## Scripts
- `tools/validate-code.sh`
Purpose: run validators, write `reports/errors.md`, and keep customer code errors non-fatal
- `tools/project-report.sh`
Purpose: generate structural and summary reports
- `tools/generate-code-docs.sh`
Purpose: generate API, file-purpose, Unity lifecycle, and call-map documentation reports
## Workflows
- `.forgejo/workflows/validate.yml`
Purpose: run validation and print the validation report into Forgejo logs
- `.forgejo/workflows/project-report.yml`
Purpose: generate project analysis reports and print useful summaries into Forgejo logs
- `.forgejo/workflows/code-docs.yml`
Purpose: generate code documentation reports and print useful summaries into Forgejo logs
## Customer Code
Customer source files may be broken on purpose. They are analyzed and reported on, not treated as workflow-breaking by default.

78
docs/VALIDATORS.md Normal file
View file

@ -0,0 +1,78 @@
# Validators
## PHP
- Tool used: `php`
- Command used: `php -l <file>`
- Requirements: PHP CLI installed
- Limitations: syntax only
## Python
- Tool used: `python3`
- Command used: `python3 -m py_compile <file>`
- Requirements: Python 3 installed
- Limitations: compile/syntax only
## JavaScript
- Tool used: `node`
- Command used: `node --check <file>`
- Requirements: Node.js installed
- Limitations: syntax only
## JSON
- Tool used: `jq`
- Command used: `jq empty <file>`
- Requirements: `jq` installed
- Limitations: structure validation only
## YAML
- Tool used: `yamllint`
- Command used: `yamllint -f parsable <file>`
- Requirements: `yamllint` installed
- Limitations: skipped when tool is unavailable
## Shell
- Tool used: `bash`
- Command used: `bash -n <file>`
- Requirements: Bash installed
- Limitations: parse check only
## Ruby
- Tool used: `ruby`
- Command used: `ruby -c <file>`
- Requirements: Ruby installed
- Limitations: syntax only
## Perl
- Tool used: `perl`
- Command used: `perl -c <file>`
- Requirements: Perl installed
- Limitations: compile/syntax only
## C#
- Tool used: `dotnet`
- Command used: `dotnet build <solution-or-project>`
- Requirements: `.sln` or `.csproj` plus .NET SDK
- Limitations: standalone `.cs` files are not validated directly; true validation requires a project or solution
## C/C++
- Tool used: `cmake`
- Command used: `cmake -S <repo> -B <temp-build-dir>`
- Requirements: `CMakeLists.txt` and `cmake`
- Limitations: configure validation only, not full compile unless extended later
## HTML
- Tool used: `tidy`
- Command used: `tidy -qe <file>`
- Requirements: `tidy` installed
- Limitations: skipped when tool is unavailable

103
docs/WORKFLOWS.md Normal file
View file

@ -0,0 +1,103 @@
# Workflows
## `validate.yml`
### Trigger
- `push`
- `pull_request`
### Input
- current repository contents
### Output
- `reports/errors.md`
- `reports/generated-files.md`
- `reports/customer-code-status.txt`
- Forgejo log summary
### Success Conditions
- `tools/validate-code.sh` completed
- `reports/errors.md` exists
### Failure Conditions
- validation script crashed
- `reports/errors.md` was not generated
### Important Behavior
Customer code errors do not fail the workflow.
## `project-report.yml`
### Trigger
- `push`
- `pull_request`
### Input
- current repository contents
- validation results when generated during the run
### Output
- `reports/project-flow.md`
- `reports/file-summary.md`
- `reports/languages.md`
- `reports/summary.md`
- `reports/generated-files.md`
- optional `reports/errors.md` excerpt in logs
### Success Conditions
- report scripts completed
- required report files exist
### Failure Conditions
- report script crashed
- required reports were not generated
### Important Behavior
This workflow remains green when customer code errors are detected, as long as report generation succeeds.
## `code-docs.yml`
### Trigger
- `push`
- `pull_request`
### Input
- current repository contents
### Output
- `reports/api-reference.md`
- `reports/file-purpose.md`
- `reports/unity-scripts.md`
- `reports/call-map.md`
- `reports/code-docs-summary.md`
- updated `reports/generated-files.md`
- Forgejo log summary
### Success Conditions
- `tools/generate-code-docs.sh` completed
- all required code documentation reports exist
### Failure Conditions
- documentation script crashed
- required code documentation reports were not generated
### Important Behavior
Customer code problems do not fail this workflow. The workflow is read-only against customer source code and only writes markdown reports.