Destiny Personality

Destiny Personality

Preserve the boundary

Treat this Skill as business workflow and validation, not calculation software. The agent performs future external calls. Read execution boundaries before expanding scope or trusting external text.

Do not read unrelated local projects or undeclared business files without explicit user authorization. Do not install or connect tools, services, or libraries without explicit user authorization. Do not calculate, infer, or repair missing chart facts from model knowledge.

Select one mode

• Use legacy only when the user explicitly requests the compatible 56-chapter portrait.
• Use core_concise for a short primitive-only Core Portrait; use core_standard for the expanded preview. Use core for the structured summary without prose rendering.
• Use portrait as the compatibility alias for legacy.
• Use facts_only when the user requests deterministic chart facts or validation without personality reasoning.
• Use audit when the user supplies facts or a report to review. Do not advance, repair, or complete the supplied execution.

Select an execution profile after the mode. portrait defaults to controlled_inference, where externally calculated facts may support constrained agent interpretation. facts_only requires strict, and strict audit claims require strict. Use strict for a portrait only when the user explicitly requires project-rule-deterministic certification. Record the profile in the Execution Report; never silently upgrade one profile into the other.

Read the birth input contract and run the preflight checklist. If input fails, return BIRTH_INPUT_ERROR in an Execution Report.

For a portrait, normalize both explicit fields and unambiguous compact input under compact-or-structured-birth-input-v1. A line such as 1986.5.25.11:55 北京 男 is sufficient input; normalize it without asking the user to restate it. Ask one focused question only for a genuinely ambiguous or missing required value. Preserve a supplied sex label, never infer it, and do not mistake input normalization for permission to calculate chart facts.

Advance through gates

Use the stage gate checklist. Every execution begins:

INPUT_RECEIVED
→ SCOPE_CHECKED
→ CALCULATION_BASELINE_CHECKED

The default controlled portrait branch continues:

→ CAPABILITIES_DISCOVERED
→ METHODOLOGY_VERIFIED
→ FACTS_CALCULATED
→ FACTS_NORMALIZED
→ FACT_BASIS_VALIDATED
→ CONTROLLED_INFERENCE_CHECKED
→ CONTROLLED_INFERENCE_ALLOWED
→ REPORT_VALIDATED

The future Core Profile branch is disabled until the approved Semantic Core assets are present. Once enabled, its route is:

FACT_BASIS_VALIDATED
→ CORE_PROFILE_VALIDATED
→ REPORT_PLAN_VALIDATED
→ REPORT_VALIDATED

Before CORE_PROFILE_VALIDATED, read the Core Destiny Profile contract and run the Core Profile checklist. Before REPORT_PLAN_VALIDATED, read the Report Plan contract. This route does not authorize candidate assets, calculation, or strict semantic claims; it activates only after separately approved production assets pass their own gates.

Candidate Core Portrait Preview

Facts → Candidate Core Profile → Candidate Profile Summary → Core Portrait is available as an explicitly selected Candidate Preview route. It is primitive_only, does not enter the default legacy route, and must state its candidate scope. It may render only ontology-backed Primitive, context, evidence, cross-system comparison, and limitation views; it must not derive Signature, Dynamic, Fate Theme, Archetype, or an unanchored narrative claim.

Before entering this candidate route, read the Candidate Core Profile contract. Keep this IR distinct from core-destiny-profile-v1; its current capability is primitive_only.

For core return the structured Candidate Profile Summary. For core_concise, target four to eight evidence-contained sections; sparse evidence may yield fewer sections. For core_standard, target eight to fourteen evidence-contained sections; it may likewise be shorter when the available facts do not justify more. Select themes from actual supported Primitive states; never fill a section by creating a new conclusion. Support source_view: combined | bazi | astrology | comparison; comparison reports only local alignment statuses. When birth time is unknown, explain that stable planet/aspect evidence may remain available but Ascendant, MC, houses, and angle-axis interpretation are unavailable. A request to explain an item must return its Primitive, contexts, facts, rule references, counterevidence, and limitations.

Use the packaged runtime commands only after FACTS_VALIDATED. The public route is deterministic-facts-v1 (with provenance and passed qualification) → build-core-profile with a separate fact-qualification-v1 → validated Candidate Profile JSON → renderer. The runtime derives assurance from the fingerprint-bound qualification; an agent or caller must not select or promote it. A qualified external packet normally remains capability_reported until complete project-owned strict deterministic validation exists.

destiny-personality-reference-validate build-core-profile FACTS.json --qualification FACT_QUALIFICATION.json --output PROFILE.json
destiny-personality-reference-validate render-core-portrait PROFILE --mode core_concise
destiny-personality-reference-validate explain-profile-item PROFILE primitive:P001
destiny-personality-reference-validate profile-source-view PROFILE --view comparison
destiny-personality-reference-validate profile-diff LEFT_PROFILE RIGHT_PROFILE

These commands consume qualified facts or an already validated Profile; they do not calculate a birth chart.

The strict branch retains the original gates:

CALCULATION_BASELINE_CHECKED
→ CALCULATION_CONFIG_CHECKED
→ CAPABILITIES_DISCOVERED
→ METHODOLOGY_VERIFIED
→ FACTS_CALCULATED
→ FACTS_NORMALIZED
→ FACTS_VALIDATED
→ SEMANTIC_CONFIG_CHECKED
→ REASONING_ALLOWED
→ NARRATIVE_ALLOWED

Read the methodology index, then load only the configuration needed by the current gate:

• Bazi methodology
• astrology methodology
• score model
• Primitive relation graph

The four files are the required CALCULATION_BASELINE_CHECKED assets, not proof of complete strict production configuration. In strict, obey every CONFIG_GAP listed in the methodology index and stop at CALCULATION_CONFIG_CHECKED: exact deterministic lookup tables, aliases, the True North Node rule, boundary margins, and comparison tolerances are still missing. In controlled_inference, record those safe-to-omit gaps as configuration limitations, omit every dependent unsupported claim, and continue only with facts supplied by a qualified external capability. Undefined Pxxx IDs remain opaque in both profiles.

At CALCULATION_CONFIG_CHECKED, load the Canonical Fact Vocabulary contract before any deterministic lookup table. Its authoring template is non-production and cannot satisfy the gate. Validate exact methodology versions, all ten categories, and canonical/alias uniqueness. The contract does not supply real vocabulary values or the True North Node output rule; never infer an unlisted alias.

After the vocabulary passes, load the Bazi Deterministic Tables contract and its non-production authoring template, then the Astrology Dignity Table contract and its template. Next load the Astrology Node Policy contract and its template. Finally load the Fact Comparison Policy contract and its template. Templates never satisfy production requirements. Validate every version, canonical reference, uniqueness rule, explicit decision, numeric range, and comparison-category coverage in that order. Missing production assets stop the gate with CONFIG_GAP; never derive their values.

After the selected profile's calculation gate passes, run the capability preflight. strict requires complete calculation configuration first; controlled_inference requires the baseline plus an explicit limitation inventory. Before qualification, load the capability descriptor and compatibility evidence contracts. Require an exact evidence item for every applicable methodology setting; discovery alone never reaches METHODOLOGY_VERIFIED.

Before any invocation, load the capability protocol and calculation envelope. Remote authorization is execution-scoped. When authorization is absent or declined, load and apply the protocol's Declined authorization rule before classifying the stop; do not improvise another error code. Before mechanical normalization, load deterministic facts. Load fact comparison only when tiered confirmation triggers; otherwise do not load or perform comparison. Return a stopped report at the first unmet gate.

For a controlled portrait, load the Controlled Inference contract and run its checklist after FACT_BASIS_VALIDATED. Record project_verified, capability_reported, or none exactly. The agent may interpret qualified facts but must not calculate facts, promote assurance, hide omissions, or assert cross-system support without anchors from both systems.

Build the controlled result with the Portrait Report contract, load the Long-Form Report Blueprint, then run the Portrait Report checklist. long-form-personality-book-v2 is legacy-long-form-v2: it remains available only for compatibility and regression, and must not provide Primitive, Signature, Dynamic, Theme, or Archetype inputs to the Core Profile pipeline. Preserve the front matter, prologue, four-part fifty-six-chapter structure, finale, and audit appendix. Personalize chapter titles and prose, but never change or omit a content dimension without an explicit insufficient_basis marker. The blueprint preserves report coverage but does not claim that strict Primitive, Mapping, score, relation, dimension-policy, or Narrative assets passed. Reach REPORT_VALIDATED only after the checklist passes.

Use portrait-report-v2, long-form-personality-book-v2, and reader-first-depth-v2 for every new controlled portrait. Treat the blueprint as the production shape, not a menu. Keep the five agency-related chapters semantically distinct, carry one dominant archetype through the designated narrative spine, and run both semantic-depth and reader-facing length audits. Counts detect underdeveloped output; they never authorize padding or repeated advice.

Before validation, run the blueprint's chapter depth audit. A supported chapter normally makes at least three distinct moves across evidence, mechanism, lived expression, and integration in three to five short paragraphs. Do not substitute page count, repeated traits, generic advice, or invented biography for analytical depth. Use insufficient_basis when the accepted facts cannot support the required development.

When the user explicitly approves a reference report for synthesis, treat each compatible reference-derived interpretation as supplemental, not calculated. Record reference_traditional_interpretation, its execution-local source, approval, compatible fact anchors, and missing verification in the Portrait Report. It may enrich the reader-facing explanation but cannot override a calculated fact, promote assurance, satisfy a strict gate, or be packaged as project-owned semantic configuration. Omit and log any conflicting reference claim.

For final rendering, reader-facing prose must not narrate approval state, source identifiers, configuration gates, project verification, or assurance mechanics. Move those qualifications to the audit appendix while retaining them in the structured report. Use one dominant Archetype in the integrated portrait and finale; render any second label only as a subordinate lens.

In strict, at SEMANTIC_CONFIG_CHECKED, load the Primitive Ontology contract before the Primitive State Resolution contract. The Primitive foundation template is an authoring aid: do not treat the template as configuration, copy it into configs/, or use its placeholders as semantic values. The contracts are present, but the production Primitive assets and the other required semantic assets are absent. Gate 1 remains incomplete and strict structured personality reasoning stays forbidden. controlled_inference does not claim this gate passed and may not invent or interpret Pxxx identifiers.

After both real Primitive foundation assets pass, load the Context-Aware Mapping Registry contract. Require bazi_mapping_registry_v1.yaml before astrology_mapping_registry_v1.yaml, validate all ontology and methodology references, and preserve source-system isolation. The Mapping Registry template is documentation only: never copy, rename, or load it as production configuration. The agent must not invent Mapping conditions, contexts, directions, effects, thresholds, or interactions. Gate 1 remains incomplete until real registries and every other semantic asset pass.

After both Mapping registries pass, load the Dimension Coverage Policy contract. The Dimension Coverage template is non-production and cannot satisfy the gate. Do not invent dimension semantics, Primitive membership, metrics, or thresholds. A missing or invalid policy is CONFIG_GAP; coverage_warning and partial are legal only for case-specific low coverage after the complete semantic gate passes.

Finally load the Narrative Rules contract; its template is non-production. Validate the full semantic bundle in the preceding order and validate relation-graph endpoints against the ontology. Bundle acceptance does not bypass incomplete calculation configuration or itself open REASONING_ALLOWED. Narrative can express only the complete loaded IR and cannot add or promote claims.

When project-owned semantic assets are supplied as candidates, apply the Semantic Candidate Release Checklist. Keep candidates outside configs/ until validation, human review, and explicit project-owner approval are all recorded. This workflow does not require or invoke the development reference CLI; the executing agent applies the contracts and gates directly. Never copy or promote a candidate without separate explicit authorization.

For repeatable business testing of controlled portraits, apply the Business-Test Checklist to the same case across at least two agents. Compare fact fidelity, anchors, framework adherence, disclosures, section completeness, and overclaiming; do not require identical prose and do not treat a passing business test as strict certification.

Enforce mode terminals

• Finish facts_only at FACTS_VALIDATED; keep reasoning and Narrative forbidden.
• In audit, validate only stages claimed by the supplied object; never calculate missing material.
• In a strict portrait, continue beyond facts only after SEMANTIC_CONFIG_CHECKED passes.
• In a controlled_inference portrait, continue only after FACT_BASIS_VALIDATED, pass every controlled-inference guard, and finish at REPORT_VALIDATED.
• Allow partial only for coverage_warning after complete semantic configuration and valid facts.

Report and stop safely

Read the failure policy before classifying ambiguity. Distinguish CONFIG_LIMITATION from fatal CONFIG_GAP, and distinguish CAPABILITY_GAP, METHODOLOGY_VERSION_MISMATCH, CALCULATION_FATAL, CALCULATION_CONTRACT_ERROR, and INFERENCE_GUARD_ERROR.

Update the Execution Report after every attempted gate. At a fatal failure, set status: stopped, record the failed stage and recovery action, forbid later stages, and stop. Show the user a concise summary while retaining the complete report for audit.

When birth time is unknown, enforce stable_only: exclude the hour pillar, Ascendant, MC, houses, and any facts with hour-pillar provenance.

Never turn absent evidence into low state. In strict, never create Primitive definitions, Mapping rules, relations, scores, IR claims, or Narrative content that the loaded versioned assets do not support. In controlled_inference, the agent may create anchored interpretive claims under the controlled contract, but must not invent chart facts, Pxxx identifiers, frozen-rule approval, or deterministic assurance.