Developing with LLMs
A vendor-neutral, copyable development context for using LLMs with Turboism.
When asking an LLM to help with Turboism development, the developer remains responsible for code quality, verification, and the final result. Follow these requirements before opening and copying the complete Markdown context.
Developer requirements
Follow the code standards
- Read and follow the current repository's contribution guidance, module conventions, and existing code style. Do not let an LLM assume the standards.
- Personally review all code that you write, modify, or accept, and confirm that it respects public SDK, permission, security, and version boundaries.
- Before submitting, run the formatting checks, static checks, tests, and builds required by the project. An LLM's explanation is not a substitute for their results.
Complete real-environment testing
- Test the code you write or accept in a real environment. Changes involving plugins, the runtime, or host integration must be verified in an authorized environment that matches the target version; simulation, successful compilation, or an LLM's assessment alone is not enough.
- Use dedicated test data and verify loading, primary behavior, failure handling, and cleanup. Do not test with user data without authorization.
- Record the test environment, relevant versions, steps, and observed results. If real-environment testing is incomplete, state that clearly and do not claim the change is ready to use.
# Turboism development context
## Role and scope
You are assisting with development for Turboism, a Java-based integration and plugin framework. Treat LLM output as a draft, not as verified code, documentation, or a completed contribution. Verify unknown facts in the current source, build configuration, tests, and documentation before acting.
Keep product documentation runtime-independent from application, learning, and plugin projects. Do not modify a host installation as a shortcut for development or testing. Identify the responsible module, its public contracts, and existing tests before editing.
## Extension boundaries
Turboism has three distinct extension paths:
1. **Java plugins** are in-process plugins with the Java SDK lifecycle, manifest, permissions, and services.
2. **GraalJS scripts** are restricted scripts that a Java plugin discovers through `PluginContext.scripts()` and explicitly runs with `ScriptService.run`; discovery alone does not execute a script.
3. **MCP** is a first-party Preview plugin that provides authenticated loopback Streamable HTTP to trusted local external clients.
ACP is internal and used only with fx; it is not a fourth extension path. The codebase targets Java 17. Preserve these Java, GraalJS, MCP, and ACP boundaries. Do not substitute one path for another just because a nearby capability appears useful.
## Development principles
- Start by reading the relevant code and checking existing issues and plugins. Avoid duplicate development and reuse established behavior where it fits.
- Prefer a general framework capability or public SDK when it can serve the need. A plugin should provide an independent function rather than duplicate shared functionality.
- Check the exact version range, required capability or provider, declared permission, and current session and lifecycle state separately. Passing one check does not establish any other check.
- Protect user data. Do not expose private materials, credentials, personal data, or other confidential content to an LLM or in a contribution.
- Remain vendor-neutral. Do not bind the design or documentation to a particular LLM provider or model without a separately verified project decision.
## Contribution and verification
Keep changes focused and add or update targeted tests when behavior changes. Before submitting a contribution, the developer must personally read the diff, inspect the changes, and check and test the result. Do not rely only on an LLM's claim that work is correct, complete, or tested.
Run the smallest relevant test first. When the current repository provides these commands, run the focused test, `devCheck`, and `checkCompletedCommit`:
```bash
./gradlew focusedTest
./gradlew devCheck
./gradlew checkCompletedCommit
```
For documentation-site changes, also run the documentation lint, type check, and production build:
```bash
npm run lint
npm run typecheck
npm run build
```
If a command, task, module, or contract is not present, confirm that from the current source or build configuration before proposing an alternative.
## Project content standards
These standards apply to content designed or submitted for this project and its community; they do not govern private use outside the project.
- Do not duplicate content.
- Do not design or submit political propaganda, pornographic content, or sensitive content unsuitable for the project community, including hateful, harassing, unlawful, or privacy-invading material.
- Keep English, Chinese, and Japanese documentation semantically aligned. Do not claim release status, downloads, compatibility, installation steps, API signatures, or availability without verification.
## Working instruction
State the source support for each material claim, distinguish verified facts from assumptions, and stop to inspect source when facts are unknown. Preserve existing boundaries and conventions, then present changes for human review.