cosmo-wander-ai/cosmo-edge

Background Task orchestration is another core CosmoEdge workflow. A beginner-friendly recipe using offline video can help new contributors understand how video sources, model nodes, post-processing, OSD, alarm rules, and output channels fit together without requiring live cameras or new algorithms. Scope Suggested files: docs/en/tutorials/04-pipeline-orchestration/pipeline-orchestration.md docs/tutorials/04-pipeline-orchestration/pipeline-orchestration.md Optional: cross-link from scenario configuration docs if useful Acceptance Criteria Add a concise beginner recipe centered on an offline video input. Explain the minimal node/task relationship in plain language. Clarify that the task should use existing capabilities; no new algorithm node is required. Include expected validation steps or manual checks for the recipe. English and Chinese docs stay aligned. Validation npm run docs:build Suggested Labels area/docs, area/pipeline, help wanted, difficulty/medium

Background Model porting is one of CosmoEdge's core workflows. A compact ONNX checklist would help contributors and interns understand the expected model metadata, labels, input shape, post-processing assumptions, and validation path before attempting a full adapter contribution. Scope Suggested files: docs/en/tutorials/05-model-porting/model-porting.md docs/tutorials/05-model-porting/model-porting.md Optional: model/resource reference docs if a cross-link is helpful Acceptance Criteria Add a minimal ONNX model porting checklist. Include expected items such as model file, labels/classes, input dimensions, preprocessing assumptions, output/post-processing expectations, and validation notes. State that large model weights and private download links should not be committed unless maintainers explicitly approve them. Keep this as documentation/checklist work only; no runtime adapter implementation is required. English and Chinese docs stay aligned. Validation npm run docs:build Suggest

Background The pull request template asks contributors to list verification commands, but first-time contributors may not know which commands fit which type of change. Adding examples will make PRs easier to prepare and review. Scope Suggested files: .github/pull_request_template.md Optional: link to CONTRIBUTING.md or the contributor guide Acceptance Criteria The PR template includes short examples for documentation, frontend, C++ tests, and x86 Docker smoke validation. The examples are concise enough that the template remains easy to scan. The template still asks contributors to list the commands they actually ran. No CI workflow behavior is changed. Validation Manual review is enough for the template change. If docs links are added, also run: npm run docs:build Suggested Labels good first issue, area/docs, area/tooling, difficulty/easy

Background Windows users are likely to try the x86 Docker path first. A short troubleshooting section can reduce setup friction around Docker Desktop, Docker Compose V2, port conflicts, and Windows path/mount behavior. Scope Suggested files: docs/en/guide/troubleshooting.md docs/guide/troubleshooting.md Optional: link from docs/en/guide/build.md and docs/guide/build.md Acceptance Criteria Add a Windows-focused x86 Docker troubleshooting section. Cover at least Docker Desktop running state, Compose V2 command format, port 8080 conflicts, and where to find x86 Docker logs. Include the Windows command variant using docker-compose.x86.windows.yml. English and Chinese docs stay aligned. Validation npm run docs:build Suggested Labels good first issue, area/docs, area/x86, difficulty/easy