Open source / Reverse engineering / Agent tools
Contribute a target or improve the framework#
中文 · SOP · Adapter contract
The framework serves user-selected software. Existing showcases demonstrate results; adding a target must not require hardcoding its name, executable, ABI or verification logic in the core.
- Define a useful task, expected native result and known public-interface gaps.
- Use the manual and workflow modes to investigate the shipped artifact and native lifecycle. Retain an operation matrix, complete entry-point cards, bounded experiments and failed hypotheses with the research helpers.
- Create an independent adapter with
init; implement its native commands, schemas and Skill. Keep platform dependencies, version pins and domain-specific verifiers in that adapter. - Register its manifest. Use the default JSON transport, or an optional hook for real compatibility requirements.
- Add task-specific assertions under the generic request/state/persistence/artifact/recovery criteria. Explain inapplicable layers and retain failures. Separate native observations from static inference, synthetic tests and historical evidence.
- Match validation to the changed behavior. Adapter behavior changes require contract checks and relevant native regression; runtime changes require core-only tests. Documentation and file-helper changes use link, template and isolated helper checks. Record check inputs, builds and results.
- Add an optional showcase entry and demo if useful. Update English/Chinese documentation and sources. A new example does not become an installation prerequisite.
Do not commit proprietary application binaries, dumps, personal documents, account configuration or bulk recordings. Publish scoped evidence and reproducible procedures; retain third-party attribution. Public APIs and external helpers may be useful parts of an adapter, but identify their provenance accurately.