Aurora tracks physical appearance as structured data, not a single text blob. Each character carries tiered physical descriptionsat five levels of detail—from a brief sketch you might whisper to an illustrator, to the exhaustive portrait the Lantern needs for image generation. Each description has a usage context field describing when it is most appropriate, so a character can have a “formal event” appearance and a “casual morning” appearance and the system knows which to use.

The Wardrobe is tracked separately from physical descriptions—because a wardrobe is an actual wardrobe, not a footnote. Each item lives as a frontmatter Markdown file inside the character’s vault (Wardrobe/*.md), with shared archetypes in the Quilltap General mount—portable, versionable, and yours. Individual garments occupy typed slots (top, bottom, footwear, and so on), while composite outfits bundle multiple pieces into a single entry—a “Rain Outfit” that includes coat, jeans, and boots. Composites carry an optionalreplace flag: when true, wearing the outfit clears the designated slots first; when false (the default), pieces layer in additively. A composite’s slot list may be a superset of its components’, so a “Naked” composite can clear everything in one gesture.

The Lantern consults the wardrobe when generating story backgrounds. The scene-state tracker resolves what each character is currently wearing based on narrative context, stored items, and scene appropriateness. The LLM wardrobe tools were renamed and consolidated into a consistent wardrobe_-prefixed CRUD-plus-wear set of seven—list, read item detail, create, edit, delete, wear, and clear—so a character can not only dress but inspect and revise its own garments. Each item may carry an optionalPortrait Cue: an image-generation phrase fed to the avatar and Lantern pipelines in place of the item’s bare title, so “the captain’s coat” renders as the coat you actually mean. The redundant wardrobe mirror table was removed; wardrobe now lives solely in the vault. And the Duplicate action in each item’s menu still produces an identical twin (composites included) with “(copy)” appended. Two newer entries join it in that same row menu: Move and Copy, each opening a destination picker that spans Quilltap General, every project, every group, and every character’s wardrobe. Copy mints a fresh item at the destination; Move carries the existing item across and removes it from the source.

As of release 4.7 the wardrobe is tri-tier, matching knowledge and scenarios: a character’s wearable garments draw from the character’s own vault, the active chat’s project stores, and Quilltap General, in that precedence. The wardrobe editor’sAdd to selector chooses where a new item is written—this character, shared everywhere, or shared to this project—and project wardrobe gets its own card on the Prospero page.

Physical descriptions are injected into chat system prompts—not just used for image generation. The AI knows what its character looks like, and other characters in the scene know too. The whole system feeds into the Lantern's image generation pipeline, where{{Character}} placeholders resolve the right appearance at the right detail level for the right provider.

Quilltap does not treat multi-character chat as “multiple one-on-one conversations happening in the same window.” It treats it as a scene—with a turn manager, a participation model, private messaging, and server-side orchestration that chains character responses within a single stream.

A Group is a cross-section of characters—parallel to how a Project is a cross-section of files and chats. Each group owns an official document store holding a description.md, aScenarios/ folder, and a Knowledge/ folder, plus zero or more additional linked stores, and surfaces Description, Scenarios, and Knowledge into chats, the Commonplace Book, and the search tool.

The scope for a given turn is the union of the stores of every group theresponding character belongs to—never the chat’s participant set, so a character never inherits a co-participant’s group stores. Groups participate in .qtap export and backup. A Groups section sits above the character grid on the Aurora page, with an editor for name, description, color, icon, members, and linked stores.

Some truths about a character are not prose. Whether they hold an ansible clearance, which faction they answer to, what tier of access their badge unlocks—these are facts, and facts want a ledger. Every character vault now admits an optional metadata.jsonat its root, alongside properties.json: a single JSON object of keys you author yourself, each holding any JSON value you please—say{ "hasAnsibleAccess": true, "clearanceLevel": 3, "faction": "Ordo Aurum" }.

The keys are yours. There are no reserved names, no schema to satisfy, no ceremony—only the requirement that the file hold an object and not a bare list or a lone number. It hydrates onto the character ascharacter.metadata, and it is a writable managed field: like pronouns or title, it lives in the vault rather than a database column, and a savereplaces the whole object at once—so removing a key is simply a matter of leaving it out.

The fact sheet is yours alone to write. No generation system touches it—not the AI Wizard, not Summon from Lore, not the Character Optimizer—and it is never folded into a system prompt or slipped into the character’s context. For now the file manager is its editing surface; there is no Aurora form for it yet. Export and import carry it faithfully, both as a character field and as the vault document itself. Its first reader is Pascal the Croupier, whose custom tools can test what the sheet holds—but that machinery keeps its own counsel at Pascal’s table.