name: vaserver-development
description: Use when working in the VAServer workspace or its algorithm, cbox, g6, ai-public modules. Guides Codex to read the shared project map, module boundaries, AI coding rules, product risk controls, testing standards, and review checklist before code or documentation changes.

VAServer Development

Use this skill for any VAServer development, review, debugging, documentation, integration, or AI-assisted coding task.

Workspace Assumption

The current workspace root should be the VAServer repository root. If ai-public/ is not present, locate the VAServer root before continuing.

Do not copy private implementation details into ai-public/. Public docs may include interfaces, behavior, constraints, shared requirements, integration notes, and standards.

Superpower Mode And Skill Principles

Use this skill as the project superpower: load the right project knowledge before acting, keep the working context focused, and turn team standards into executable checks.

Follow Karpathy-style skill principles:

• Skills are compact operational memory, not long essays.
• Load only the references needed for the current task.
• Prefer reusable workflow and checklists over one-off prompting.
• Keep detailed standards in ai-public/90_standards/; this skill only routes and enforces.
• If a repeated pattern appears during work, propose adding or updating a skill or reference instead of relying on chat memory.

Start Every Task

1. Read the minimum project context:
   • ai-public/00_project_map/project-overview.md
   • ai-public/00_project_map/repo-map.md
   • ai-public/00_project_map/module-boundaries.md
   • ai-public/00_project_map/ai-entry-guide.md
2. Read common rules:
   • ai-public/90_standards/ai-coding-rules-common.md
   • ai-public/90_standards/coding-standard.md
3. Identify the touched module and read its rule file:
   • algorithm: ai-public/90_standards/ai-coding-rules-algorithm.md
   • cbox: ai-public/90_standards/ai-coding-rules-cbox.md
   • g6: ai-public/90_standards/ai-coding-rules-g6.md
4. If the task crosses modules, read relevant interface docs under ai-public/20_interfaces/ before changing code.

Phase Review Gates

Every non-trivial task must pass four review gates. Do not skip a gate unless the task is clearly Level 1 and no code, interface, config, data format, deployment behavior, or test behavior changes.

1. Requirements Review

Before design or coding, restate:

• user goal and acceptance criteria
• touched module or modules
• public interface impact
• product risk level, especially S/A risk
• missing information or assumptions

If requirements are ambiguous and a wrong assumption could create product risk, ask before implementing.

2. Design Review

Before implementation, outline:

• intended approach and affected files
• compatibility and rollback considerations
• abnormal handling and logging
• test strategy
• open risks

For cross-module or S/A-risk work, require explicit human confirmation or a clearly documented existing decision before changing behavior.

3. Development Review

During implementation, check:

• change scope stays within the reviewed design
• public interfaces and historical data/config compatibility are preserved
• no private implementation details are moved into public docs
• risk controls from product-risk-control-standard.md are implemented when applicable
• code follows existing module patterns

If implementation diverges from the design, stop and update the design review notes before continuing.

4. Test Review

Before final response, review:

• tests run
• tests not run and why
• manual hardware, field, model, or legacy toolchain validation still needed
• regression risk
• evidence that S/A-risk protections were checked

Risk Gate

Always check whether the task involves any of these areas:

• time sync, device time, NTP, GPS
• capture, illegal/violation data, speed, upload
• false capture, abnormal burst data, enforcement result
• upgrade, rollback, compatibility, data format migration
• configuration, persistent settings, calibration line, detection area
• storage, logs, Flash, EMMC, SD/TF card, SSD, disk full
• watchdog, deadlock/hang, abnormal reboot, power loss recovery
• algorithm metrics, signal abnormality, PTZ/ball camera control

If yes, read ai-public/90_standards/product-risk-control-standard.md before implementation. Treat enforcement data, time sync, speed, upload, and false-capture protection as S-level risk unless the project documents say otherwise.

For S/A-level risk, the final response or task record must state:

• protection mechanism
• abnormal-data isolation behavior
• compatibility or rollback impact
• tests run and tests not run
• remaining hardware, field, or manual validation risk

Implementation Rules

• Keep changes local to the requested module and existing ownership boundaries.
• Preserve public interfaces unless an interface change is explicitly requested and documented.
• Do not silently change runtime configuration, calibration, detection regions, or historical data formats.
• Do not introduce frequent writes to Flash/EMMC or program directories.
• Keep logs centralized, bounded, and cleanable.
• For algorithm work, define inputs, outputs, dimensions, units, boundary conditions, metrics, and verification method.
• For embedded/g6 work, consider memory, real-time behavior, power, blocking waits, hardware protection, watchdog, and reboot behavior.
• For cbox/service work, preserve service stability, logging, configuration, rollback path, upload behavior, and compatibility.

Testing And Review

Before finalizing, read:

• ai-public/90_standards/testing-standard.md
• ai-public/90_standards/code-review-checklist.md

Report:

• what changed
• why it changed
• result of requirements, design, development, and test reviews
• tests or verification performed
• tests not performed and why
• remaining risk, especially S/A-level product risk

If tests cannot be run because hardware, model, field environment, or legacy toolchain is missing, say so directly and name the manual validation needed.