Skip to content

feat(signage): AI image generation functions (PPT-2741) - #30

Open
camreeves wants to merge 3 commits into
masterfrom
feat/signage-ai
Open

feat(signage): AI image generation functions (PPT-2741)#30
camreeves wants to merge 3 commits into
masterfrom
feat/signage-ai

Conversation

@camreeves

Copy link
Copy Markdown
Contributor

Part of the AI signage feature (PPT-2741). No ordering constraint: it can merge whenever, and nothing currently in the tree depends on it.

What this adds

Client functions and types for the signage AI endpoints added in PlaceOS/rest-api#447: generate, edit, claim, job query and show, cancel, the provider CRUD, the provider test, capabilities, and usage.

Notes for review

One deviation worth a decision. A persisted resource in this repo usually comes back as a model class built by a process function, and roughly 35 endpoint families do that. SignageAIProvider here is a plain interface instead. I went looking for a precedent for the interface approach and did not find one, so this is inconsistent rather than justified. It is a small change to make it a class if you would rather it matched.

Testing

569 tests pass, build is clean.

Creeves and others added 2 commits August 31, 2026 15:09
Mirrors the SignageAI controller: capabilities, generate, edit, the long
polling job read, the caller's job list, cancel, claim, usage and the
provider CRUD.

showSignageAIJob goes through show rather than query: the request blocks
server side for up to 25 seconds, so it must not be cached or folded in
with a concurrent one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…akes

The endpoint answers for the domain the request is made against, and forces the
row's domain on create. Leaving these in the SDK meant a consumer could pass a
domain, get somebody else's answer in their head, and no error.
@MrYuion

MrYuion commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

@camreeves can you remove any justification paragraphs in the comments. It's unnecessary fluff for consumers of the library.

Review feedback: the comments explained why the implementation is the way it
is, which is fluff for anyone reading the code and, in ts-client, for anyone
consuming the library. user-interfaces already says as much in AGENTS.md —
"comments should only explain hard to understand code not justify
implementation".

What each thing does, the @PARAM tags, and notes on mechanics a reader cannot
infer — an external API quirk, a magic number's unit, an ordering requirement —
all stay. Comments only, no behavioural change.
@camreeves

Copy link
Copy Markdown
Contributor Author

@camreeves can you remove any justification paragraphs in the comments. It's unnecessary fluff for consumers of the library.

Oh yep no worries, I've done that now (and on the other repos too).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants