@tiinex/app 0.1.1

package/src/transitions/canonical-schema-cache/053d46ce082d4ec261b82abc44ecca403d61e240/tiinex.schema.generation.v1.schema.md

@@ -0,0 +1,379 @@
+# Continuity Context
+
+- Envelope Schema: [tiinex.root.v1](../../../tiinex.root.v1.schema.md)
+- Parent
+  - Parent Schema: [tiinex.schema.contract.v1](../tiinex.schema.contract.v1.schema.md)
+  - Created At: 2026-07-02 00:00:00
+  - Trace: [tiinex.schema.contract.v1.schema.md](../tiinex.schema.contract.v1.schema.md)
+  - Origin:
+    - [relative](../tiinex.schema.contract.v1.schema.md)
+    - [browse + git](https://github.com/Tiinex/docs/blob/1669696ea4f498adf8924476c9f3bc8313993689/.topics/.schemas/schema/contract/tiinex.schema.contract.v1.schema.md)
+- Current
+  - Current Schema: [tiinex.schema.generation.v1](tiinex.schema.generation.v1.schema.md)
+  - Created At: 2026-07-02 00:00:00
+  - Status: Draft schema proposal
+  - Why: Defines generation contract nodes so schema builders can ask for required inputs, create artifact skeletons, fill defaults, and preserve unknowns without inventing semantics.
+  - Summary: Schema generation contract for reliable artifact creation and authoring flows.
+
+---
+
+
+# Schema Generation
+
+## Summary
+
+Defines a contract for generating a schema-guided artifact or artifact skeleton.
+
+A schema generation contract describes what inputs are needed, what sections and fields should be produced, what defaults may be used, what unknowns must be preserved, and what text is only placeholder guidance. It supports form builders, schema builders, CLI tools, LLM-assisted authoring, and human checklists without making the schema software-bound.
+
+Schema generation does not prove the generated artifact is true, complete, valid, or semantically wise. It only describes a bounded creation process.
+
+## Core Semantics
+
+- Schema generation = bounded creation guidance for artifact skeletons or filled artifacts.
+- Generation should distinguish required human input, default values, derived values, adapter-provided values, and unknown placeholders.
+- Generation should not invent provenance, targets, evidence, validation, or claims.
+- A generated artifact should remain reviewable by humans and validators.
+- Generation rules should point to section, field, value, rule, relation, and inheritance contracts where possible.
+
+## Schema Validation Contract
+
+### Generation Scope
+
+Applies To
+
+- artifacts whose `Current -> Current Schema` is `tiinex.schema.generation.v1`
+
+Rules
+
+- `tiinex.schema.generation.v1` identifies a contract node for creating schema-guided artifact content or skeletons.
+- Generation artifacts must preserve target schema, input requirements, generation steps, output boundary, unknown handling, and interpretation limits.
+- Prose outside `Schema Validation Contract` may explain the schema, but it does not add required validation rules.
+
+### Generation Body
+
+Required Shape
+
+- first body heading after the continuity envelope
+- `## Generation Identity` section
+- `## Generation Target` section
+- `## Required Inputs` section
+- `## Generation Steps` section
+- `## Output Boundary` section
+- `## Interpretation Limits` section
+
+Optional Sections
+
+- `Prompt Surface`
+- `Defaulting`
+- `Derived Values`
+- `Placeholder Policy`
+- `Review Policy`
+- `Examples`
+- `Relationship to Other Schemas`
+
+Rules
+
+- Generation steps should be ordered when order matters.
+- Generated defaults must not pretend to be observed, verified, or human-provided.
+- Unknown required inputs must be preserved as unknown or requested, not silently omitted.
+
+### Generation Identity
+
+Required Fields
+
+- Generation Handle
+- Generation Name
+- Generation Kind
+
+Optional Fields
+
+- Generation Version
+- Generation Owner
+- Generation Mode
+
+Allowed Labels
+
+- artifact-skeleton
+- artifact-filled
+- schema-skeleton
+- form-flow
+- prompt-flow
+- repair-flow
+- migration-flow
+- unknown
+
+Rules
+
+- Generation kind should state whether the contract creates a skeleton, a filled artifact, a form flow, a prompt flow, a repair, or a migration.
+
+### Generation Target
+
+Required Fields
+
+- Target Schema
+- Target Output
+
+Optional Fields
+
+- Target Artifact Kind
+- Target Section Contracts
+- Target Field Contracts
+- Target Rule Contracts
+- Parent Schema
+- Child Schema
+
+Rules
+
+- Target schema must identify what kind of artifact is generated.
+- Target output should state whether the output is a full artifact, partial artifact, section, field set, or repair suggestion.
+
+### Required Inputs
+
+Entry Shape
+
+- First-Level Hyphen List Item
+
+Required Fields
+
+- Input Source Policy
+
+Optional Fields
+
+- Optional Input
+- Derived Input
+- Defaultable Input
+- User Prompt
+- Adapter Source
+- LLM Assistance Allowed
+- Unknown Handling
+
+Allowed Labels
+
+- human-input
+- adapter-input
+- imported-input
+- derived-input
+- defaulted-input
+- llm-suggested-input
+- unknown
+
+Rules
+
+- Each first-level entry is one required-input declaration.
+- The declaration name is the readable Required Input identity and must be unique within `## Required Inputs`.
+- Each input entry owns its own `Input Source Policy`; source policy must not be paired by list position or document-wide field order.
+- Input source policy must distinguish human input, adapter input, imported input, derived input, defaulted input, and LLM-suggested input.
+- LLM-suggested input must remain suggested unless reviewed or verified.
+
+### Generation Steps
+
+Entry Shape
+
+- First-Level Hyphen List Item
+
+Required Fields
+
+- Step Action
+
+Optional Fields
+
+- Step Order
+- Uses Section Contract
+- Uses Field Contract
+- Uses Rule Contract
+- Uses Value Contract
+- Condition
+- On Missing Input
+- Review Needed
+
+Allowed Labels
+
+- create-section
+- create-field
+- fill-value
+- derive-value
+- ask-user
+- mark-unknown
+- add-limit
+- link-related-artifact
+- review
+- unknown
+
+Rules
+
+- Each first-level entry is one generation-step declaration.
+- The declaration name is the existing readable `Step Handle` identity and must be unique within `## Generation Steps`.
+- Step-local fields belong to that declaration; validators must not pair repeated Step Action/Order values by document position.
+- Step order should be explicit when deterministic generation requires it.
+- Missing input handling must be explicit for required fields.
+- Generation steps must not silently create evidence, claims, validations, or preservation artifacts.
+
+### Output Boundary
+
+Required Fields
+
+- Output Kind
+- Review State
+
+Optional Fields
+
+- Completeness Boundary
+- Validation Boundary
+- Placeholder Policy
+- Mutation Policy
+- Save Policy
+
+Allowed Labels
+
+- skeleton
+- draft
+- filled-draft
+- repair-suggestion
+- migration-suggestion
+- reviewed
+- unknown
+
+Rules
+
+- Output kind must state whether the generated content is a skeleton, draft, suggestion, or reviewed artifact.
+- Review state must not be overstated.
+
+### Interpretation Limits
+
+Required Fields
+
+- Does Not Mean
+- Must Not Be Used To Claim
+
+Optional Fields
+
+- Overclaim Risk
+- Missing Input Risk
+- Review Boundary
+
+Rules
+
+- Generated content does not prove its own correctness.
+- A generated artifact should still be validated by the relevant schema and reviewed when semantics matter.
+
+## Artifact Creation Contract
+
+### Creation Scope
+
+Required Fields
+
+- Create When
+- Do Not Create When
+
+Rules
+
+- Create a generation contract when artifact creation should be repeatable, form-buildable, promptable, or repairable without repeatedly interpreting schema prose.
+- Do not create a generation contract when creation is entirely manual and no reusable input or step contract exists.
+
+### Creation Inputs
+
+Required Fields
+
+- Generation Handle
+- Target Schema
+- Target Output
+- Required Inputs
+- Generation Steps
+- Output Boundary
+- Interpretation Limits
+
+Optional Fields
+
+- Defaults
+- Derived Values
+- Prompt Surface
+- Examples
+
+Rules
+
+- Required inputs should map to field or section contracts when possible.
+- Generation steps should be small and ordered.
+
+### Generation Rules
+
+Rules
+
+- Build the skeleton before filling optional values.
+- Ask or mark unknown before inventing required provenance.
+- Preserve source, method, state, and interpretation limits where the target schema requires them.
+- Run validation after generation when a validator exists.
+
+## Validation-Friendly Shape
+
+- Generation Handle, target schema, input source policy, step handles, and output kind should be extractable as field values.
+- Unknown input handling should be explicit.
+- Generated examples should identify whether they are skeletons, drafts, or reviewed artifacts.
+
+## Minimal Example
+
+```text
+# Schema Generation: Annotation skeleton
+
+## Generation Identity
+
+Generation Handle: annotation-skeleton
+Generation Name: Annotation skeleton generation
+Generation Kind: artifact-skeleton
+
+## Generation Target
+
+Target Schema: tiinex.annotation.v1
+Target Output: full artifact skeleton
+
+## Required Inputs
+
+- Target Identifier
+  - Input Source Policy: human-input
+- Annotation Kind
+  - Input Source Policy: human-input
+- Annotation Value
+  - Input Source Policy: human-input
+
+## Generation Steps
+
+- create-annotation-target-section
+  - Step Action: create-section
+  - Step Order: 10
+  - Uses Section Contract: annotation-target
+
+- fill-target-identifier
+  - Step Action: ask-user
+  - Step Order: 20
+  - Uses Field Contract: target-identifier
+  - On Missing Input: mark-unknown
+
+## Output Boundary
+
+Output Kind: skeleton
+Review State: unreviewed draft
+
+## Interpretation Limits
+
+Does Not Mean: the annotation value is correct
+Must Not Be Used To Claim: target or value has been validated
+```
+
+## Relationship to Other Schemas
+
+- `schema.section`, `schema.field`, and `schema.value` provide generation building blocks.
+- `schema.rule` may produce repair flows.
+- `interaction.unit` may expose generation inputs as UI or human interaction units.
+- `validation.report` may record post-generation validation.
+
+---
+
+# Continuity Integrity
+
+- sha256-base64url-c14n-v1
+  - Towards: [tiinex.schema.contract.v1.schema.md](https://github.com/Tiinex/docs/blob/1669696ea4f498adf8924476c9f3bc8313993689/.topics/.schemas/schema/contract/tiinex.schema.contract.v1.schema.md)
+  - Value: N3HHx97V1jljnruVv5EpxBnQqgJiUUtul7yXWfSuJJ8
+
+- sha256-base64url-c14n-v2
+  - Towards: self
+  - Value: IYfPs40EcSSOOeogvE6zvhdDcbUTf-p5En3dh-PM4NE

package/src/transitions/canonical-schema-cache/053d46ce082d4ec261b82abc44ecca403d61e240/tiinex.schema.transition.companion.v1.schema.md

@@ -0,0 +1,265 @@
+# Continuity Context
+
+- Envelope Schema: [tiinex.root.v1](../../../tiinex.root.v1.schema.md)
+- Parent
+  - Parent Schema: [tiinex.root.v1](../../../tiinex.root.v1.schema.md)
+  - Created At: 2026-08-17 00:00:00
+  - Trace: [tiinex.root.v1.schema.md](../../../tiinex.root.v1.schema.md)
+  - Origin:
+    - [browse + git](https://github.com/Tiinex/docs/blob/d69b8ff55a56b8cb9282b8684db6a938a4435b94/.topics/.schemas/tiinex.root.v1.schema.md)
+- Current
+  - Current Schema: [tiinex.schema.transition.companion.v1](tiinex.schema.transition.companion.v1.schema.md)
+  - Created At: 2026-08-17 00:00:00
+  - Status: Draft schema proposal
+  - Why: Defines explicit schema-local candidate attachments to canonical Transition Definition artifacts without copying Transition behavior or relying on application-code-only registries.
+  - Summary: Portable schema-local Transition attachment companion.
+
+---
+
+# Schema Transition Companion
+
+## Summary
+
+Defines an explicit schema-local attachment set over canonical Transition Definition artifacts.
+
+A Schema Transition Companion answers one bounded question:
+
+```text
+Which exact canonical Transition Definitions does this schema explicitly include in its local candidate semantic neighborhood?
+```
+
+It does not restate Transition roles, outputs, lifecycle, mapping, relations, placement, generation, conditions, runtime qualification, or product presentation.
+
+## Core Semantics
+
+- Companion = explicit schema-local candidate attachment authority.
+- Transition Definition artifact = sole canonical Transition semantic truth.
+- Attachment = exact reference to one Transition Definition representation.
+- Attachment does not prove schema participation, applicability, execution support, UI visibility, ordering, or recommendation.
+- No companion and an explicitly empty companion are different states.
+- Parent/child schema ancestry does not implicitly inherit Transition attachments in v1.
+- The same canonical Transition representation may be attached explicitly by multiple schema companions without duplicating the Transition Definition source.
+- Paths and filenames are navigation, not Transition identity.
+
+## Schema Validation Contract
+
+### Schema Transition Companion Scope
+
+Applies To
+
+- artifacts whose `Current -> Current Schema` is `tiinex.schema.transition.companion.v1`
+
+Rules
+
+- `tiinex.schema.transition.companion.v1` identifies artifacts whose main job is to declare one schema's explicit local candidate Transition attachments.
+- A companion must identify exactly one schema through `Schema Reference`.
+- A companion must not duplicate Transition Definition behavior fields.
+- Prose outside `Schema Validation Contract` may explain attachment intent but does not add machine attachment semantics.
+
+### Schema Transition Companion Body
+
+Required Shape
+
+- first body heading after the continuity envelope
+- `## Schema Binding` section
+- `## Transition Attachments` section
+- `## Interpretation Limits` section
+
+Rules
+
+- `## Transition Attachments` may contain zero or more attachment declarations.
+- An explicitly empty attachment set must contain one literal first-level entry named `none` and no other entries.
+
+### Schema Binding
+
+Required Fields
+
+- Schema Reference
+
+Optional Fields
+
+- Note
+
+Field Value Constraints
+
+- Schema Reference
+  - Allowed Shape: Markdown Link
+  - Domain Policy: closed
+
+Rules
+
+- `Schema Reference` must resolve to exactly one schema artifact.
+- The resolved target artifact, not the companion filename or directory name, determines which schema the companion binds.
+- A package-internal Schema Reference should use a relative Markdown link that remains inside the declared package boundary.
+- A reference that cannot resolve to exactly one schema artifact leaves the companion binding unresolved.
+- Within one selected semantic package compilation, more than one companion resolving to the same exact schema artifact is competing attachment authority and must fail closed; v1 does not merge companion attachment sets implicitly.
+- `Note` is human-readable context only and must not add schema or Transition semantics.
+
+### Transition Attachment Declaration
+
+Entry Shape
+
+- First-Level Hyphen List Item
+
+Required Fields
+
+- Transition Reference
+
+Optional Fields
+
+- Note
+
+Field Value Constraints
+
+- Transition Reference
+  - Allowed Shape: Markdown Link
+  - Domain Policy: closed
+
+Rules
+
+- Entries under `## Transition Attachments` are repeated named declarations using this shape.
+- The declaration name is a companion-local readability handle only and is not Transition identity.
+- `Transition Reference` must resolve to exactly one artifact whose `Current -> Current Schema` is `tiinex.transition.definition.v1`.
+- A package-internal Transition Reference may be relative only when its target remains inside the same declared semantic package boundary.
+- An external Transition Reference must be reachable through an explicitly included/dependent package route in the active Semantic Package Manifest context; filesystem or network reachability alone is not package authority.
+- A missing or unavailable exact Transition Reference remains an unresolved attachment and must not be replaced by registry-name guessing.
+- An ambiguous Transition Reference fails closed.
+- Two attachment entries that resolve to the same exact concrete Transition representation are duplicate attachments and invalid even if their local declaration names differ.
+- Two different Transition representations that share `Canonical Identifier` and `Version` are not duplicate attachments merely because those fields match.
+- The literal entry `none` is allowed only as the sole `## Transition Attachments` entry and is exempt from declaration fields.
+- `Note` is non-authoritative readability context and must not restate Input Roles, Output Roles, lifecycle, effects, relations, placement, generation, conditions, product ordering, or UI presentation.
+
+### Attachment Qualification
+
+Rules
+
+- Attachment declaration and Transition participation are separate truths.
+- After resolving an attachment, a compiler may compare the bound schema artifact with the referenced Transition Definition's resolved role/schema authority.
+- When the canonical Transition Definition explicitly and exactly references the bound schema in a participating Input Role or Output Role, the attachment is participation-consistent.
+- When all relevant role/schema authority is fully resolved and definitively excludes the bound schema, the attachment remains a declared source reference but companion qualification contains a contradiction and must fail closed.
+- When Transition role/schema authority is generic, unconstrained, or unresolved such that participation cannot be proven or disproven, attachment participation remains unresolved; the compiler must not invent participation.
+- Schema ancestry must not be used as an implicit assignability rule when checking attachment participation.
+- This qualification step must not modify or restate the Transition Definition.
+
+### Companion Absence And Explicit Empty State
+
+Rules
+
+- Absence of a Schema Transition Companion means no explicit schema-local attachment authority is declared.
+- Absence must not cause a compiler to infer attachments from every Transition Definition in the package registry.
+- A companion whose `## Transition Attachments` contains only `none` explicitly declares an empty attachment set.
+- An explicit empty attachment set is different from companion absence and should remain distinguishable in compiled provenance.
+- A Transition Definition may exist in the package registry without being attached by a schema companion; registry existence does not imply attachment.
+- The same Transition Definition may be explicitly attached by Topic and Task companions at the same time while remaining one canonical Transition artifact.
+
+### Schema Inheritance Boundary
+
+Rules
+
+- Transition attachments do not implicitly inherit through schema Parent/descendant relationships in v1.
+- A child schema with no companion does not inherit its parent's attachment set.
+- A parent and child may both explicitly attach the same exact Transition Definition; both attachment declarations retain separate companion provenance.
+- This schema does not authorize schema-assignability inference.
+
+### Registry Identity And Dedupe
+
+Rules
+
+- Companion declaration names, paths, filenames, Transition `Canonical Identifier`, and Transition `Version` are not universal representation identity.
+- Exact concrete representation sameness may support compiled dedupe only when separately provable.
+- Distinct representations sharing Canonical Identifier and Version must remain distinct candidates.
+- Compiled attachment projections must preserve companion source, schema binding, Transition reference, resolved representation, and package/discovery provenance.
+
+### Interpretation Limits
+
+Required Fields
+
+- Does Not Mean
+- Must Not Be Used To Claim
+
+Rules
+
+- Attachment does not prove schema participation unless canonical Transition truth independently supports that participation.
+- Attachment does not prove current applicability, executability, authorization, output existence, runtime support, product visibility, recommendation, or ordering.
+- The companion must not become a second Transition registry or behavior ontology.
+- Product/UI projection remains outside this schema.
+
+## Artifact Creation Contract
+
+### Creation Scope
+
+Required Fields
+
+- Create When
+- Do Not Create When
+
+Rules
+
+- Create a Schema Transition Companion when one schema needs an explicit portable candidate attachment set that should survive without application JavaScript.
+- Do not create a companion merely because a Transition Definition references the schema somewhere in canonical Transition semantics.
+- Do not use a companion to copy or summarize Transition behavior fields.
+- Do not create implicit inherited companion behavior in v1.
+
+### Required Inputs
+
+Required Fields
+
+- Schema Reference
+- Transition Attachments
+- Interpretation Limits
+
+Rules
+
+- A schema may intentionally use an empty attachment set.
+- Missing or unresolved Transition references should remain explicit rather than being replaced by registry heuristics.
+
+### Generation Rules
+
+Rules
+
+- Bind the companion to one exact schema artifact.
+- Add one exact Transition Reference per intended candidate attachment.
+- Keep human notes short and non-authoritative.
+- Do not add role, lifecycle, effect, relation, placement, generation, condition, ordering, or UI fields to attachment entries.
+
+## Minimal Example
+
+```text
+# Task Transition Companion
+
+## Schema Binding
+
+Schema Reference: [tiinex.task.v1](tiinex.task.v1.schema.md)
+Note: Explicit Task-local candidate Transition neighborhood.
+
+## Transition Attachments
+
+- topic-to-task
+  - Transition Reference: [Topic to Task](.transitions/topic-to-task-transition-definition.trace.md)
+  - Note: Candidate attachment only; canonical Transition Definition owns behavior.
+
+- finding-to-task
+  - Transition Reference: [Finding to Task](.transitions/finding-to-task-transition-definition.trace.md)
+
+- issue-to-task
+  - Transition Reference: [Issue to Task](.transitions/issue-to-task-transition-definition.trace.md)
+
+## Interpretation Limits
+
+Does Not Mean: every attached Transition is currently applicable, executable, supported, recommended, or visible in a UI
+Must Not Be Used To Claim: that Task participates in a Transition unless the referenced canonical Transition Definition independently supports that participation
+```
+
+## File Naming
+
+- Schema Transition Companion artifacts should use `<schema-id>-transitions.trace.md`.
+- Example: `tiinex.task.v1-transitions.trace.md`.
+- The filename is schema-local navigation only and is not schema identity, Transition identity, participation authority, or package identity.
+
+---
+
+# Continuity Integrity
+
+- sha256-base64url-c14n-v2
+  - Towards: self
+  - Value: QIgH3N5Jbf3wStEYA7XSVL7J0vNaRaSr8p1hZEonam0