How to use AI for a Python integration

Replace bracketed values before sending the prompt. Give the assistant the relevant public files from the exact target release; use synthetic examples and keep credentials, private campaigns and proprietary material out of its context.

What you will build

Build a read-only campaign report from authorized actor/journal data. Run it in an isolated development installation with a caller who really belongs to the campaign.

Context to give the assistant

• The Python interface section in docs/en/api.md and the exports under api/.

• docs/en/architecture.md: membership, Context, service boundaries and post-commit events.

• The target host version and the real signatures/tests of the public functions needed by the report.

Step by step

1. Separate a trusted server integration from a browser module; the browser does not receive arbitrary Python execution.

2. Choose the caller and campaign explicitly; constructing Context does not grant permission.

3. Ask for a read-only implementation first, using the facade and current projections.

4. If a later change writes data, review its request identity, expected revision and notifications separately.

Copy and adapt this prompt

Repository: [local checkout or public repository]
Target host release: [installed/requested version; preserve it]
Task scope and authorization: [what may be changed/published]

Implement a read-only campaign report in trusted Python code for this target release.
Initialize Django using the documented environment. Inspect the exports and signatures in api/ and use api.Context for the explicit campaign/user. Do not guess a REST endpoint or API-key scheme.
Read only the resources the caller may access; do not bypass the API with direct ORM queries, private host imports or database writes.
Return a short synthetic example and structured error handling for missing membership, permission denial and missing resources.
Keep configuration, temporary output and caches in the installation or explicitly selected disposable test directory. Do not read real credentials into logs or reports.

Inspect the actual files and supported APIs before proposing code. Do not invent commands, fields, endpoints or package capabilities.
Use disposable test data and installation-local tools/caches. Explain any unsupported requirement and validate the result with the project’s real tools.
Deliver concrete files or editor steps, the checks performed and any unresolved limits.

How to validate

• Compare a GM report with an authorized player report and confirm hidden resources are filtered before output.

• Attempt a different campaign and a revoked membership; confirm access fails.

• Check that generating the report does not change database content or send chat/dice messages.

Ready when

The report uses supported public functions, exposes only the caller’s authorized data and has no write side effects.

Continue with the module reference, public API and testing guide.