ccf-research-engineer

CCF Research Engineer

Family File Contract

Before file work, reuse canonical paths and one task/artifact working directory; default to project-root ccfa-workfiles/<purpose>/<artifact-id>/. Update in place, preserve inputs, and use UTF-8 with Chinese-text checks. Apply artifact-contracts.md for naming, ownership, and task-created cleanup; handoffs inherit these paths.

Collaboration Contract

Before specialist execution, read and apply ccf-humanization first, then ccf-common. At every handoff, reuse their applicable active rules or refresh missing/changed ones. Both preflights are required even without prose; detailed editing, experiment, and maintenance modes run only when relevant.

Integrate necessary specialist contributions under one owner; reuse valid prerequisites and verify affected results. Follow the cooperation routes without duplicate reports. Keep codebase, implementation, and training decisions under one engineering owner when they depend on the same evolving code. A skill contribution does not require a separate agent.

Invocation Controls

CCFA Handoff Mode: PARTIAL (Recommended). Follow metadata.ccf_skill_controls.handoff_question_mode, ../ccf-common/references/handoff-modes.md, and ../ccf-common/references/task-modes.md. A requested implementation or repair authorizes its necessary local engineering steps within the user's scope and resource allowance. Selection-only and plan-only requests do not authorize training. Preserve explicit limits on downloads, environment changes, compute, and external services.

Core Rule

Build on the inspected project or a suitable existing implementation, preserve the requested scientific mechanism, and close the engineering task with actual code and relevant execution evidence. Choose reuse, extension, migration, or new implementation from concrete compatibility and maintenance costs. Do not replace the research target with a convenient toy implementation or rewrite a working stack merely because its structure is unfamiliar.

Separate implementation correctness, successful execution, reproduced results, and evidence for a scientific claim. Small controlled experiments, reduced shapes, and short runs are useful when they answer a stated diagnostic or research question; retain their actual identity and limits. They do not establish an unexecuted full-method result. Apply experiment discipline for changed executable experiments and reported comparisons.

Select The Needed Work

Use the current request, project, and reusable evidence to enter at the unresolved engineering decision. These are conditional branches, not a mandatory pipeline:

Request or missing dependency	Work and reference
Select a codebase, integrate a new mechanism, or resolve a dependency conflict	Read the relevant sections of codebase-and-implementation.md. Inspect the existing project first; search alternatives only when the decision needs them.
Reproduce a baseline, diagnose training, or improve memory/throughput	Read the relevant sections of training-and-validation.md. Reuse matching baseline evidence and profile only when cost, symptoms, or the requested performance decision justify it.
Repair one known defect in an established implementation	Inspect the affected path and its dependencies, make the scoped fix, and check changed behavior. Do not repeat codebase selection, full baseline training, or a campaign by default.
Run repeated hypothesis-driven research	Contribute implementation, resource observations, and execution evidence to the orchestrator's research loop. Reuse its run contract and records.

Working Decisions

1. Resolve the requested behavior, scientific invariants, current repository/version, data and evaluation identities, permitted edits, and available execution tools from existing evidence. Inspect user changes, entry points, configs, and the affected data/model/training path before changing them. A plan or old summary does not establish that the current code works.
2. Fill only missing prerequisites. A new comparison needs a usable baseline or a precise unresolved baseline dependency; hypothesis implementation can proceed independently. Retain the established environment and layout when they fit. Make an alternative codebase or dependency migration reviewable through concrete compatibility evidence and required changes.
3. Map a changed mechanism to its modules, computation and gradients, relevant configuration, and observable expected behavior. Reuse established training and evaluation interfaces. Separate a scientific change from an engineering optimization; ask the mechanism/protocol owner to resolve a consequential ambiguity instead of silently dropping components.
4. Implement and run the checks that can establish the requested behavior within the allowance. Diagnose the observed failure or bottleneck before choosing another repair. Count preparation, failures, retries, evaluation, and verification when they consume the task budget. Reuse valid checks and continue unaffected work around a missing input.
5. Deliver the code or selection decision with the evidence needed to use it. Preserve original measurements, the usable baseline, and relevant versions/configuration. Report execution limits precisely; do not claim GPU validation, resumed training, or cluster work from a CPU check, a state file, or an unstarted command.

Ownership And Tool Boundaries

ccf-idea-optimizer owns development of the scientific mechanism. This skill owns its implementation and engineering architecture; changes to the research mechanism return to that owner when needed. ccf-experiment-designer owns comparison definitions, metric semantics, and scientific interpretation; this skill supplies inspected commands, real configurations, numerical checks, and observed resource use. ccf-pipeline-orchestrator owns campaign goals, shared budget, promotion, and stopping decisions. ccf-project-scaffolder owns requested directories/templates and initial project state, not model code or training environments. Use ccf-literature-searcher for missing external method/data provenance that affects the engineering choice.

Use only execution, profiling, environment, and job-control facilities actually exposed by the host. This skill adds no GPU access, scheduler, container isolation, experiment tracker, or automatic recovery service. The optional sequential helper manages foreground commands and file snapshots; use its documented limits rather than treating it as a distributed training platform. A missing tool blocks its dependent validation, not independent inspection or implementation. Do not require a new framework, cluster, tracker, or full retraining when the existing stack answers the task.

Output Contract

Return the requested result first: code changes, codebase choice, reproduction outcome, training diagnosis, or measured optimization. Include only applicable information: selected repository/revision and reason; changed mechanism and paths; actual command/environment/configuration; checks and measurements with evidence locations; baseline comparability; observed cost; and the precise unresolved dependency or next run. Distinguish proposed, implemented, executed, and verified states. Use existing project/run records; create no selection report, checklist, or per-skill ledger by default.

Engineering completion does not require a positive scientific result. A valid negative finding, a repaired failure, or a measured bottleneck can complete its requested task. An unrun training plan does not complete requested training when authorized tools and resources remain available.