@tiinex/app 0.1.1

package/src/tooling/portable/schema/fixtures/tiinex.schema.generation.v1.repeated-record.contract-fixture.md

@@ -0,0 +1,98 @@
+<!-- Contract-only fixture transcribed from Tiinex/docs@068241174421716b941421e95931ec5a6e95b0da. -->
+# Continuity Context
+
+- Envelope Schema: tiinex.root.v1
+- Parent
+  - Parent Schema: tiinex.schema.contract.v1
+  - Trace: parent.trace.md
+  - Origin: parent.trace.md
+- Current
+  - Current Schema: tiinex.schema.generation.v1
+  - Created At: 2026-08-16 00:00:00
+
+---
+
+# Schema Generation
+
+## Schema Validation Contract
+
+### 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.

package/src/tooling/portable/schema/fixtures/tiinex.schema.inheritance.v1.repeated-record.contract-fixture.md

@@ -0,0 +1,58 @@
+<!-- Contract-only fixture transcribed from Tiinex/docs@068241174421716b941421e95931ec5a6e95b0da. -->
+# Continuity Context
+
+- Envelope Schema: tiinex.root.v1
+- Parent
+  - Parent Schema: tiinex.schema.contract.v1
+  - Trace: parent.trace.md
+  - Origin: parent.trace.md
+- Current
+  - Current Schema: tiinex.schema.inheritance.v1
+  - Created At: 2026-08-16 00:00:00
+
+---
+
+# Schema Inheritance
+
+## Schema Validation Contract
+
+### Merge Rules
+
+Entry Shape
+
+- First-Level Hyphen List Item
+
+Required Fields
+
+- Merge Operation
+- Applies To
+
+Optional Fields
+
+- Parent Node
+- Child Node
+- Reason
+- Condition
+- Effective Result
+
+Allowed Labels
+
+- inherit
+- add
+- refine
+- override
+- deprecate
+- forbid
+- rename
+- migrate
+- unknown
+
+Rules
+
+- Each first-level entry is one merge-rule declaration.
+- The declaration name must be unique within `## Merge Rules` and must be a readable local description composed from the rule's existing semantic material, such as merge operation plus applies-to scope; it is not a global identifier.
+- Merge operation and applies-to remain explicit nested fields and must not be inferred from declaration position.
+- Merge operation must be explicit.
+- `override` must identify the parent node being overridden.
+- `refine` should preserve parent intent while narrowing or clarifying it.
+- `add` must not remove inherited obligations.

package/src/tooling/portable/schema/fixtures/tiinex.task.v1.contract-fixture.md

@@ -0,0 +1,165 @@
+<!-- Contract-only test fixture for Tiinex/docs@3c1987527c431660c4fc6eab4af24f503653034b. Not a canonical snapshot; only machine-authoritative contract surfaces are retained. -->
+# Continuity Context
+
+- Envelope Schema: tiinex.root.v1
+- Parent
+  - Parent Schema: tiinex.root.v1
+  - Trace: root.trace.md
+  - Origin: root.trace.md
+- Current
+  - Current Schema: tiinex.task.v1
+  - Created At: 2026-08-15 00:00:00
+
+---
+
+# Task
+
+## Schema Validation Contract
+
+### Task Scope
+
+Applies To
+
+- artifacts whose `Current -> Current Schema` is `tiinex.task.v1`
+
+Rules
+
+- `tiinex.task.v1` identifies artifacts centered on one bounded unit of work.
+- The body should make the requested work legible without requiring special tooling.
+- A task artifact should let a later reader tell what work is in scope now and what counts as done.
+- Prose outside `Schema Validation Contract` may explain the schema, but it does not add required validation rules.
+
+### Task Body
+
+Required Shape
+
+- first body heading after the continuity envelope
+- readable prose or lists that state the concrete work, completion signal, and boundaries
+
+Optional Sections
+
+- Subtasks
+- Risks
+- Open Questions
+- Requested Work
+- Acceptance Criteria
+- Blockers
+
+Rules
+
+- A task artifact should begin with a human-readable title.
+- A task artifact should contain enough body content that a later reader can identify the work being requested now.
+- The body should make the current boundaries or constraints readable rather than hiding them in terse metadata.
+- Follow-up sections must not replace the concrete work statement or completion signal.
+- If the artifact becomes mostly design exploration instead of bounded work, another schema should own it instead.
+
+### Task Semantics
+
+Allowed Shapes
+
+- standalone task
+- task with dependencies
+- task with recursive subtasks
+- blocked task with explicit dependency signal
+- task with concrete origin targets
+
+Rules
+
+- A task artifact should make the requested work explicit.
+- A task artifact should make clear what completion means for the current task.
+- A task artifact should make clear what constraints, non-goals, or boundaries still apply.
+- When the task depends on concrete files, traces, or other durable artifacts, the artifact should prefer explicit readable target references over vague mentions.
+- Recursive subtasks are allowed when they clarify execution, but the current task should remain the primary reading unit.
+
+### Task Envelope Companions
+
+Optional Fields
+
+- `Current -> Why`
+- `Current -> Summary`
+- `Current -> Authors`
+- `Current -> Origin`
+
+Rules
+
+- Task artifacts may carry light current-side metadata when it helps a reader orient quickly.
+- Task artifacts should declare parent signal when they continue, refine, or decompose an earlier local artifact.
+- Task artifacts should avoid turning envelope metadata into the only place where the requested work is described.
+
+### File Naming
+
+Allowed Shapes
+
+- `<lineage>.trace.md`
+- `<lineage>-<task-slug>.trace.md`
+
+Rules
+
+- Task artifacts should keep the lineage label first.
+- The optional slug should describe the concrete work slice.
+- Task artifacts should prefer short human-readable slugs.
+- Task artifacts should keep the `.trace.md` suffix stable.
+
+### Interpretation Boundaries
+
+Rules
+
+- Use `tiinex.task.v1` when the artifact is mainly defining concrete work and completion criteria.
+- Do not use `tiinex.task.v1` for broad design exploration without a bounded work request.
+- Do not use `tiinex.task.v1` for thin pointers or passive evidence capture.
+- If the artifact's main job is to land what now governs rather than what should be done, another schema should own it.
+
+## Artifact Creation Contract
+
+### Prompt Fields
+
+Required Fields
+
+- version
+- createTitle
+- summaryPrompt
+- summaryPlaceholder
+
+Optional Fields
+
+- whyPrompt
+- whyPlaceholder
+
+Rules
+
+- The current task create surface uses version `1`.
+- `createTitle` should label the create action as `Create Task`.
+- `summaryPrompt` should ask for the task title.
+- `summaryPlaceholder` should guide the user toward the concrete work to be done.
+- `whyPrompt` and `whyPlaceholder` may be omitted when create flow does not ask for a why field.
+
+### Template Body
+
+Required Shape
+
+- first heading uses `# {{summary}}`
+- `## Objective` section
+- `## Done Criteria` section
+- `## Scope` section
+- `## Dependencies` section
+
+Rules
+
+- Generated task artifacts should begin with the task title as the first body heading.
+- `Objective` should describe the concrete work being asked for.
+- `Done Criteria` should define what completion means for the task.
+- `Scope` should capture boundaries, constraints, and non-goals.
+- `Dependencies` should capture blockers, required artifacts, or prerequisite work when they exist.
+- Tools should preserve the same generated body shape even when they use a maintained built-in template.
+
+---
+
+# Continuity Integrity
+
+- sha256-base64url-c14n-v1
+  - Towards: [tiinex.root.v1.schema.md](https://github.com/Tiinex/docs/blob/00adbcc5b0319410cf16752a54dcbf4813173040/.topics/.schemas/tiinex.root.v1.schema.md)
+  - Value: BFWYft1v0Ue0gUoO236DGScvnixS7_MIEwO6mhJhkNw
+
+- sha256-base64url-c14n-v2
+  - Towards: self
+  - Value: SVkacZ6IRAHU68znToXLqDvAKAVRMUqdZHJNAVmmcBc