Build on the Wisent App platform.

The web application's manual Create wizard keeps the complete name, description and appearance entered by the user. Character Settings → Edit Character also keeps the complete name and description. These fields are not silently shortened. The manual wizard still requires a nonblank name and a processed profile image before completion.

Names and descriptions are saved in the character record. Appearance is an input to image generation, not a saved description: the image step removes surrounding whitespace and adds the selected avatar style's prompt modifier. Generation, crop, moderation and private image upload remain separate operations whose results must succeed; a preview alone is not proof of a stored image.

Authenticated clients create with POST /api/characters, read with GET /api/characters/ID, edit with PUT /api/characters/ID, and delete with DELETE /api/characters/ID. JSON creation and update bodies carry the complete name and description. Read the detail operation after an update to observe the saved values, rather than treating a success response as persistence evidence.

Missing authentication is refused. Another account cannot edit or delete an owned character; an inaccessible record can be reported as not found rather than forbidden. Database failures remain failures. Deletion reports deleted or unassigned: a public character with other people's conversations can lose its author association without being erased. New private qualification characters must be deleted, not merely unassigned.

Quick Mode keeps the complete description and requires only nonblank input in the application. Select Generate, review the saved private character or room, then select Create to open it. The final button navigates to records already saved by generation. Authenticated clients use POST /api/autogenerate/createwith description and type: character, room or auto. Character success returns the character; room success returns the room and its generated characters.

Wisent Backend still owns the accepted character-description range through AUTOGENERATE_DESCRIPTION_MIN_CHARS and AUTOGENERATE_DESCRIPTION_MAX_CHARS. The application sends a complete trimmed character description. For rooms it saves the complete trimmed scene and sends complete participant segments without a word or participant-count cut. A character-service refusal keeps its actual status and response body; the wizard displays the service detail without clearing the input. Blank requests are refused. Any failed room participant fails the room request and reports its cause. Generated characters from that attempt are discarded only while owned, private and unused; cleanup refusals retain the character ID and actual cause.

Both room creation forms and Room Settings → Edit room keep complete names and descriptions and do not impose the former participant cap. Authenticated POST /api/rooms requires name, an explicit characterIds array and optional description and entryMessages array. An empty participant array creates an empty room through the API; manual screens require a selected character. Missing arrays, blank names, duplicate IDs and another account's private characters are refused. The room wizard requires a nonblank name, not a local minimum name length. Its qualification checks whitespace refusal, short-name progression and a short name saved unchanged through the shorter room form. The full room wizard also keeps the complete image prompt, without a length cap or remaining-character counter. It trims surrounding whitespace, adds the existing wide-angle interior instruction and sends the chosen room style separately to generation; image-service failures remain failures.

Manual and quick creation save the private room and all participants in one create_private_room transaction. Read GET /api/rooms/ID and GET /api/rooms/ID/participantsto observe saved state, edit with PUT /api/rooms/ID, and delete with DELETE /api/rooms/ID. Deletion removes participants and retains existing conversations with their room association cleared.

The supported account-data CLI imports and exports canonical account records; it does not provide separate character-management commands. The web and authenticated server operations above are the character lifecycle interfaces.

From the application checkout, run node tests/characters/retention.mjs --fixture .build/character-fixture.jsonon a Stado-selected dedicated Weles host. The private fixture selects dedicated accounts, an exclusive authenticated English-language browser profile, real application and database URLs, meaningful long text, the model and avatar style, and independently retained evidence for the exact deployed source revision.

The journey creates, reads, edits, reloads and deletes a real private character; exercises actual image generation, moderation and display; checks authentication and ownership refusals; and reads the database after changes and cleanup. It keeps source revision, commands, exit statuses, complete responses, screenshots and supported Weles recordings under the checkout's ignored build directory. Missing prerequisites are blocked, not passed. Failed cleanup remains a failure, and media and analytics service records are not claimed to have been erased with the character.

Quick creation has a separate real journey: node tests/characters/quick-retention.mjs --fixture .build/quick-character-fixture.json. It requires an exclusive initially empty account, the real backend's declared bounds, independent application/backend/schema release evidence, and long character and room descriptions. It compares real backend refusals with application and wizard results, checks retained participant facts and actual saved rows, and checks partial room failure cleanup. Both manual room forms select beyond the former cap; the full wizard generates and displays a real room image. The editor saves and reloads long text, adds another participant and deletes through its confirmation dialog. Cleanup deletes rooms before characters through normal APIs and confirms the account's character and room state is empty. Existing data prevents the run; missing prerequisites are blocked, not passed. Retained conversations, media and analytics remain service records. These commands describe qualification, not a claim that an unrun journey passed.

The local backend reads deployment-owned configuration, not a developer’s paths or account. Standalone MLX server variants and model diagnostics require MODEL_PATH, naming the actual local model directory or model repository. Missing or blank input stops startup with a message naming MODEL_PATH; a failed load retains its cause. This requirement does not replace the main authenticated API’s model-selection contract.

Configure APNS_KEY_ID, APNS_TEAM_ID, APNS_KEY_PATH and FASTAPI_ENDPOINT for the selected deployment. An empty example field is not a usable signing identity or callback. Deliver credentials through Stado’s secret synchronization, never in command arguments or committed environment files.

Cloud consumers require deployment-owned AWS_REGION, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, with AWS_S3_BUCKET_NAME for storage and LOG_GROUP_NAME for CloudWatch logging. No account key, bucket or log group is selected by source. Missing or blank inputs are refused as “CloudWatch logging requires explicit settings:” or “CloudWatch metrics requires explicit settings:”, followed by the missing names, never credential values. AWS_ENABLED selects S3 versus local storage; it does not disable the existing CloudWatch consumers. The unused ALERT_EMAILS setting and obsolete AWS_SECRET_KEY alias are removed; no alert-mail consumer used that setting.

From the local backend checkout, run bash infrastructure/runtime/launch ROLE with absolute WISENT_MLX_ROOT and WISENT_MLX_PYTHON inputs. The roles are api, gunicorn, worker and beat; trailing arguments go to the selected native process. The api role starts Uvicorn from app/: pass the deployment’s declared bind host, port and worker count through --host, --port and --workers. The launcher does not install or restart a managed service. Missing or relative paths and an unknown role return 2; an unavailable application directory or Python executable returns 1 and names the path. --help needs no inputs.

Declare the installed launcher through stado service ensure, with the selected host, /bin/bash as --from, the launcher and role as --arg values, and non-secret deployment paths as --env values. Stado owns the service identity, permissions, lifecycle and graphical service controls. Use one product unit per selected host, not source-owned systemd files or direct instance-update scripts. Read back the managed service and complete an actual API request or queue job before calling the deployment usable; process health alone does not establish that result.

Redis has Terraform and CloudFormation definitions under infrastructure/redis/. Choose one owner per resource. Terraform requires region, vpc_id, subnet_ids and deployment_name; node_count selects one through six nodes. Run terraform init, terraform apply -var-file=.build/deployment.tfvars.json, terraform output -json and terraform destroy with that same variables file and retained private state. Run these commands from infrastructure/redis/ and keep provider cache and state under its ignored .build/ directory. A single node disables failover and multi-AZ.

CloudFormation requires VpcId, SubnetIds and AllowedCidr and retains two-node HA. Use aws cloudformation deploy with the template and explicit parameters to create or update a named stack, describe-stacks to read it, and delete-stack followed by wait stack-delete-complete to remove it. Physical resource names belong to that stack. Both definitions retain plaintext Redis transport within the selected network. Check actual network membership and a write/read/delete from an authorized consumer, not just the returned endpoint. Keep connection output private.

The repository’s tests/models/local.test.mjs exercises real local inference and undeclared-model refusal. tests/infrastructure/redis.test.mjs provisions, updates, reads and deletes isolated real Redis resources through both definitions. Run them with node --test and the explicit private fixtures documented in the repository. Model qualification requires a Stado-selected Apple Silicon host and independently known model output; Redis qualification requires an authorized dedicated account and incurs cloud charges. Reports retain source revision, commands, status and observed state under .build/. Source delivery or a health response is not a qualification result, and these journeys do not qualify simulated prototype endpoints.

Run node --test tests/cloudwatch/runtime.test.mjs with the owner-only WISENT_MLX_CLOUDWATCH_FIXTURE described in the repository README. It requires an explicitly authorized dedicated cloud account, real chat identity and model, selected host, log group and independently known response, logs and metric values. The journey checks cloud account ownership, actual missing-setting refusal, real API inference through the normal launcher and provider log and metric readback. It stops only its own isolated process. An unconfirmed provider read is awaiting_observation; point WISENT_MLX_CLOUDWATCH_OBSERVATION at the retained report to read without another inference request. Source delivery, logger construction and process health do not qualify these consumers.