focusreactive / focusreactive/payload-plugins
translator: an async systemPrompt builder with collection, document and run context
- Dominant language
- TypeScript
- Stars
- 19
- Forks
- 0
- Avg merge
- 16h 54m
- Merged PRs (30d)
- 19
Description
Read against **0.10.1**.
## Problem
Two seams see less than a host needs, and together they make prompt customisation per collection or
per run impossible.
**`SystemPromptBuilder` is synchronous**, and its whole context is:
```ts
{ sourceLang, targetLang, defaultPrompt }
```
No `payload` handle, no collection, no document. So nothing can be read from the CMS inside it. A
builder that closes over a cache does not help, because it cannot await a cache warm — the first call
after a cold boot would use an empty cache and say nothing about it.
**The provider sees text and nothing else.** `translate(input, sourceLng, targetLng)` where
`input: Record` — bare indexed strings, no collection, no document id, no run
reference.
## Why this matters
We inject a terminology glossary into the system prompt. Because of the two facts above:
- We cannot use `systemPrompt` at all, and instead wrap `TranslationProvider` with our own async
`translate` that resolves the glossary and constructs `createOpenAIProvider` per call with the terms
baked into a closure. That works, but the wrapper exists purely to get an `await`.
- **Per-collection and per-run glossary scoping is unimplementable at any price.** A term that should
apply to machine-model pages but not to careers listings cannot be expressed, because nothing at
either seam knows which collection is being translated. This is not a workaround we have not found;
the information is not present.
## Suggested shape
Make `systemPrompt` awaitable, and widen its context:
```ts
type SystemPromptContext = {
sourceLang: string
targetLang: string
defaultPrompt: string
collection?: string
documentId?: string | number
payload?: Payload
}
type SystemPromptBuilder = (ctx: SystemPromptContext) => string | Promise
```
Accepting a promise is backwards-compatible with existing synchronous builders. Passing the same
context through to `TranslationProvider.translate` would close the gap on the provider side too.
Contributor guide
No contributing guide indexed for this repository
Research direction
Locate the translator's SystemPromptBuilder, TranslationProvider.translate, and createOpenAIProvider entry points. Trace how the current context and indexed input are passed, then verify the proposed async context reaches prompt builders and providers while synchronous builders remain compatible. Done means collection, document, run, and payload context are available for per-scope prompt customization.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- backend-api-design
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100