Current capabilities and limitations

Scope: Creator Source Package v1 compiled by the current local_owner_synthetic_preview target

阅读中文版

This page prevents target-design ideas from being mistaken for fields that work today. For exact syntax, use the generated v1 field reference.

Source capability is not runtime availability

Most rows below describe what Creator Source Package v1 can encode and what the compiler validates. They do not mean that every mechanism is already executable in the current application. The latest local owner preview supports ordinary model-backed conversation, a minimal process-local turn trace, one explicit owner checkpoint, a character-owned bounded decision, a deterministic outcome, and a public wait state. Current application code also implements a second explicit owner checkpoint that publishes a validated proactive return. When the committed branch declares an optional progression.aftermath chain, later checkpoints walk the chain one authored beat at a time: a creator-fixed beat advances — committing that beat's fixed world event and showing its public away copy — and each beat's validated return publishes only its proactive message. When the next beat is decision-bearing (a beat carrying decision_phase), the checkpoint re-arms a decision instead of an advance: it commits that beat's own Creator-bounded decision, its world event carries the chosen outcome's facts, and the beat's return conveys that outcome through the outcome's return follow-up. A structured Journal entry and a public-safe causal timeline attach only to the branch's final return, and the Journal covers the union of every decision the branch committed; the package-approved static outcome visual is optional per outcome and publishes with the final return only when the Creator authored a depiction for the final outcome. Packages without a chain keep the two-checkpoint shape. After a return is published, later ordinary turns reconstruct the committed current-branch decision, the outcome the character observed, the selected Creator-approved disclosure grant, the exact return, and its relevant commitments; alternate branches and unobserved facts do not gain disclosure authority. A promise the user makes in ordinary chat can become a durable reciprocal agreement (#327, slice 1): when the package declares reciprocal_promise, the Character Actor may propose a commitment_candidate naming the compiled agreement, cited from the user's own words and gated by the same confidence authority as influence; the reply must acknowledge it as pending, and only a later user message the Actor reads as a commitment_operation (confirm or decline) activates or closes every promise of the agreement atomically inside the ordinary-turn join. The player shows a platform note while the agreement awaits confirmation and the Creator-exact presentation_after_activation lines once it is active; the decision-window commitment_state predicate and renegotiation are not yet implemented. Progression is explicit by default: a relationship pinned to the accelerated TimeMappingProfile (#325) has the return after each committed beat and the advance into the next creator-fixed beat delivered by the clock process, while every decision stays an explicit checkpoint; there is no external notification or live image generation. A successful compile also does not install or activate an arbitrary new package in that preview.

Capability matrix

Area	Current v1 support	Important boundary
Package shape	One manifest plus six fixed, required YAML modules and declared assets	No optional module filenames, plugin modules, or partial-package compile
Character	One primary character with identity, values, contradiction, goals, portrayal limits, knowledge, disclosure posture, voice, and refusal guidance	No package-authored model prompt or private mutable runtime state
Relationship	Remote-confidant channel, semantic influence vocabulary, durable episodes, optional invented shared context, and optional reciprocal promise	User has no physical presence or direct NPC channel and cannot mutate character/world state
World and arc	One bounded arc with facts, locations, NPCs, narrative time/deadline, typed decision eligibility, decision envelopes, deterministic outcomes, and follow-ups	Character Actor chooses only inside the authored space; World/GM owns outcomes
Progression	Arc Progression V1 with initial scalar beliefs, accepted-influence predicates, deadline-position predicates, one horizon, silence semantics, close-unresolved guidance, and optional branch-scoped aftermath beat chains after one committed branch-decision outcome; each creator-fixed beat is an away/return cycle with its own world event, follow-up, and public away copy, and a beat may instead carry decision_phase (a decision-bearing beat whose entry checkpoint is a further Creator-bounded decision)	One decision per phase instance; a decision-bearing beat is never the chain's first; chains branch only from branch-decision outcomes; no pre-decision contact phases and no seasons; the current CLI target requires progression even though the base source model marks it optional
Conversation availability	Immediate conversation and optional declared deferred follow-up with bounded wake, cutoff, expiry, and return decision; while the character is away the user may leave messages (留字, #326) — accepted and sequenced, no turn runs, frozen into the return and given to the Character Actor; optional dialogue.away_composer_placeholder	Operational timing does not become narrative time; consumer pacing remains open
Dialogue	Exact opening, guided ordinary conversation, exact terminal recovery anchor, guided degraded recovery, semantic-lock follow-ups/expiry, and exact Journal copy	No arbitrary new dialogue mode and no raw-text routing
Disclosure	Knowledge limits, disclosable facts, dialogue exclusions, observed-fact gates, follow-up reveal/withhold options, and visual exclusions	No typed multi-turn probe threshold or persistent staged-secret progression
Visuals	One existing portrait, optional public discovery cover/hook/crop/fact boundary, and at most one optional existing outcome asset per outcome, with visual intent and provenance	A text-only outcome may omit its depiction; discovery is required for catalog placement; no live image generation; source provenance is not approval
Creator Portal	PostgreSQL-backed browsing of repository-seeded packages and revisions, text replacement, validation, exact source ZIP download, and one cached non-activatable Preview Bundle per revision/fixed profile	A Registry or Preview Bundle entry does not imply Workbench/Test Lab evidence, approval, qualification, publication, activation, or runtime selection
Acceptance evidence	Semantic cases and paraphrase ranges tied to influence and decision IDs	Evidence does not directly route runtime behavior and the authoring CLI does not run a full Creator evaluation workflow
Compilation	Deterministic full-package lowering to canonical IR and content-addressed runtime bundle; reproducibility check	Compiler does not call an LLM, approve, qualify, publish, or activate
Application today	Local ordinary conversation, minimal turn trace, explicit manual checkpoints (decision, then beat-by-beat advance/return when the committed branch has an aftermath chain, re-arming a decision at each decision-bearing beat), bounded character decisions, deterministic outcome/wait states, validated proactive returns, a final-return-only Journal (union of committed decisions) and public-safe timeline with a per-outcome optional approved static visual, and branch-scoped post-return conversation continuity	No scheduling beyond the opt-in TimeMappingProfile (#325; decisions stay explicit), no external notification, live image generation, multi-episode memory, or tester, consumer, public, remote, or third-party data authorization

Locale behavior

The current platform presentation catalog contains exactly two supported locale entries:

• en-US
• zh-CN

One package version chooses one package.default_locale. The compiler uses it to select platform-owned unavailable and phase copy. All CHAT_ONLY and DEGRADED_CHAT recovery declarations must use the same locale.

arc.progression.decision_phase.no_eligible_guidance.public_projection.text, and the same field inside each decision-bearing beat's decision_phase.no_eligible_guidance, is a locale map. It must contain the package default and may contain both en-US and zh-CN.

Most other Creator-authored copy—including the display name, character guidance, exact opening, semantic obligations, Journal, alt text, and each aftermath beat's title, narrative_gap, and away_projection—is a single string, not a locale map. Therefore:

• an en-US package can compile and receive English platform copy;
• a zh-CN package can compile and receive Chinese platform copy;
• one source version does not automatically provide a complete bilingual experience; and
• the current compiler does not translate, check translation parity, or select localized variants for those single-string fields.

Do not add ad hoc translations, locale_variants, or parallel localized fields; the closed schema rejects them. A complete dual-language authoring and release strategy remains a product/schema decision. The documentation itself is bilingual so both English- and Chinese-speaking collaborators can author against the same current contract.

Progressive disclosure

The v1 source contract can encode, and the compiler can validate, coarse and outcome-aware withholding:

1. say what the character may know and ordinarily reveal;
2. mark initial world facts user_disclosable: false where appropriate;
3. list fact IDs ordinary or follow-up dialogue must not disclose;
4. commit outcome facts, then separately define what the character observes;
5. give each follow-up bounded reveal/withhold options; and
6. prevent private facts from appearing in outcome art.

It does not provide typed persistent stages such as “unmentioned → hinted after a gentle probe → partially admitted after trust → fully disclosed,” and the current application does not record that the user has learned one of those stages.

Once one proactive return is successfully published, ordinary conversation may continue to reference the outcome facts allowed by that selected disclosure option. The runtime grant is scoped to the current relationship and committed outcome. It does not expose facts from alternate outcomes, facts the character did not observe, or facts the Creator prohibited from public use. The broad authoring proposal discusses richer disclosure intent, but that is not permission to invent fields today. Until a new accepted schema/runtime contract lands, use current fact guards only for the boundaries they actually enforce and call the richer behavior unsupported.

Post-decision aftermath beat chains

progression.aftermath is an optional block that splits one outcome's consequences into an ordered chain of public beats, advanced one at a time by the explicit owner checkpoint. The current contract and compiler enforce:

• Each chain binds one branch-decision outcome through branch_of (a decision-bearing beat's outcome cannot carry a further chain), with at most one chain per outcome; beats is ordered and non-empty, and beat IDs are unique across chains.
• A creator-fixed beat declares id, title, narrative_gap, a world_event (committed_fact_ids, optional npc_cause_ids), a followup_id, and an away_projection. A decision-bearing beat declares decision_phase instead and must not author world_event or followup_id (see the next section).
• Fact partition: each creator-fixed beat's committed_fact_ids must come from its branch outcome's committed facts, beats may not overlap, and at least one fact must stay with the outcome and commit immediately with the decision — every branch fact commits exactly once across the outcome and its creator-fixed beats. A decision-bearing beat claims nothing from the branch outcome closure: it commits its chosen outcome's own facts.
• Follow-up correspondence: every outcome has exactly one outcome-return follow-up; each creator-fixed beat additionally claims exactly one dedicated arc follow-up, one follow-up cannot serve two beats, and a beat follow-up's outcome_id must equal the chain's branch_of. A decision-bearing beat claims no dedicated follow-up — its return publishes through the chosen outcome's outcome-return follow-up.
• Wake coverage: declaring aftermath requires the deferred follow-up away contract, and conversation_availability.deferred_followup.consequence_return_wake_condition must cover each beat's compiled consequence phase ref (consequence-phase:<branch_of>:<beat_id>) exactly once — decision-bearing beats included; the field is rejected when no aftermath exists.
• away_projection is the public copy shown for that beat's wait state, and the Creator beat title appears only in material published after the beat has committed. Outcome visuals are per-outcome optional with at most one depiction each; the Journal still publishes only with the branch's final return and covers the union of every decision the branch committed.

The exact structural constraints live in the generated v1 field reference.

Decision-bearing beats: decision_phase on a consequence beat

One beat in an aftermath chain may carry decision_phase, making it a decision-bearing beat: after the prior beat's return commits and conversation reopens, that beat's entry checkpoint re-arms a decision, and the character chooses again among that beat's candidate envelopes. The current contract, compiler, and runtime enforce:

• decision_phase declares id (a bare id of at most 40 characters, unique against the branch decision phase and every other decision-bearing beat), candidate_decision_ids, input_window, no_eligible_guidance, and silence.
• Decision partition: the branch decision_phase and every decision-bearing beat carry pairwise-disjoint candidate sets whose union covers arc.decisions exactly once — one decision belongs to exactly one phase. The checkpoint offers only the pending group's envelopes and never mixes in another phase's candidates.
• Each candidate decision still maps to exactly one outcome, and every candidate outcome must commit at least one fact; committing the beat decision commits a world event carrying the chosen outcome's facts, and the return conveys that outcome through its outcome-return follow-up. Candidate outcome visuals are optional: a text-only outcome is valid.
• input_window accepts only first_readiness_event or since_prior_decision (until_decision_horizon is rejected — a decision-bearing beat closes its input at the consequence return that triggers it). Every decision freezes its own half-open influence window: the lower bound is strictly above the prior committed decision's frozen input cut, the upper bound includes its own cut; since_prior_decision pins the lower bound explicitly at the prior decision's frozen boundary. At most one decision commits per phase instance, and windows are pairwise disjoint.
• Do not (and cannot) author for a decision-bearing beat: world_event and followup_id (facts live on outcomes; returns are keyed per outcome), its own readiness edge (the compiler derives the entry from the prior beat return's character_observed_consequence_return wake vocabulary with a fixed on_triggering_event input closure), a decision-bearing beat at the chain's first position (it needs the prior beat's return as its entry), or an aftermath chain hanging off a decision-bearing beat's outcome.
• At runtime this rides the release capability explicit_public_beat_checkpoint_v3: the envelope names every decision-bearing beat's decision request group in compiled order, and a v1/v2 envelope over a bundle containing decision-bearing beats fails closed instead of loading unreachable content. The checkpoint control keeps neutral copy and discloses no beat title or candidate material before commit. Silence never advances or decides anything, and wall-clock time never selects or locks a decision; under an opt-in TimeMappingProfile (#325) it may only deliver an already-authorized return or creator-fixed advance.

Current compiler constraints that are easy to miss

• source-package.yaml plus all six modules are required, and their filenames are fixed.
• The package ID is one lowercase/hyphenated path segment; package ID and version must match both directory and manifest.
• Every model is closed: extra fields are errors.
• Values must be canonical. Floats, non-string mapping keys, non-JavaScript-safe integers, duplicate YAML keys, and unsafe values are rejected.
• Source roots, modules, and assets cannot use symlinks or path traversal.
• Portrait and outcome assets must use .avif, .gif, .jpeg, .jpg, .png, .svg, or .webp; discovery covers use the static raster subset .avif, .jpeg, .jpg, .png, or .webp. The compiler binds their bytes and provenance into the bundle.
• Provider, prompt, operational, approval, release, and raw-text routing fields are forbidden anywhere in Creator YAML, including disguised key spellings and routing constructs embedded in strings.
• One world deadline and Arc Progression V1 are required by the current build target.
• Every decision must map one-to-one to an outcome. Every outcome must have exactly one outcome-return arc follow-up and at most one visual depiction (a depicted outcome must exist; a text-only outcome may omit its visual); each creator-fixed aftermath beat claims exactly one additional follow-up on its branch outcome, while a decision-bearing beat claims none; every follow-up ID must have one dialogue entry, and every outcome has one Journal statement.
• The Journal additionally needs exactly one statement per influence kind and decision.
• The current CLI compiles only full_package for local_owner_synthetic_preview.
• The constructive-refusal style anchor used as exact CHAT_ONLY recovery text cannot exceed 8,000 Unicode code points.
• opening.generated_reply_suggestions is structurally a boolean, but the current pilot examples keep it false and accepted decisions leave broader suggested-reply enablement open. Successful compilation of true would not grant product-release authority.

See the semantic guide for the larger reference graph and the quickstart troubleshooting table for common error families.

Internal and synthetic examples are not templates

An internal Chinese reference package exercises more optional mechanisms than a first package needs. Its identity, source content, and assets are not part of this public guide.

The Orbital Garden Relay package is a smaller English portability canary and demonstrates package-local assets, typed progression, deferred follow-up, and localized no-eligible guidance. It is synthetic test material, not production content, Creator approval, or a rights assertion.

Neither is a scaffold. Preserve their structure only when it matches the new story's authored meaning.

Provenance role boundary

The v1 provenance[].role field accepts only:

• historical_hybrid
• governing_product_decision
• semantic_normalization_authority
• synthetic_fixture_origin

That vocabulary is sufficient for the existing historical normalization and synthetic canary, but it is not a general model for original manuscripts, licenses, visual sources, or Creator corrections. Do not label a real source inaccurately merely to satisfy the schema. If none of these roles is truthful, record the contract gap and extend the contract through review before relying on the new source. A provenance reference records traceability; it does not by itself prove rights, consent, Creator approval, or asset approval.

Current Portal package access

The Portal can now browse PostgreSQL-backed projects, packages, versions, immutable revisions, and files, and download an exact revision as a deterministic ZIP. On the current draft HEAD, it can replace one existing package-local UTF-8 text file and append a new immutable revision with expected-HEAD conflict detection. Fang can explicitly validate any selected immutable revision; the Portal persists and displays its passed/failed state, typed diagnostics, and duration. Validation does not block saving an incomplete draft or move its HEAD. The Portal still cannot add, rename, or delete paths, edit binary or reserved historical assets, compile, freeze, approve, or activate a package.

Proposed or open—not current v1

The following may appear in product/specification discussions but are not current authoring-CLI or Portal capabilities:

• a Creator Portal editor that gathers intent without exposing raw YAML;
• ingestion of arbitrary IP documents into a reviewed draft package;
• a general schema for fully localized package copy and translation parity;
• pre-decision establishment or contact phases, cross-arc continuation or carryover, seasons, and ambient beat scheduling (current aftermath chains are post-decision, branch-scoped, and advance only through the explicit owner checkpoint; further decisions exist only as authored decision-bearing beats inside such a chain, one decision per phase instance);
• typed multi-turn, trust/probe-gated progressive disclosure;
• Creator-selectable model, prompt, image-generation, or training recipes;
• live media generation;
• automatic rights, consent, or asset-approval adjudication;
• a package command that publishes or activates its output;
• tester/consumer use, public release, or production proactive delivery; and
• every dialogue, reward, ending, sharing, scheduling, or memory feature described as open in broader proposals.

The broader Creator authoring proposal is valuable design context, but its proposed and historical sections are not a field reference. A material new capability needs an explicit product decision, typed contract, compiler/runtime enforcement, tests, and documentation before an author can rely on it.