pyinto 0.0.1__tar.gz

pyinto-0.0.1/CHANGELOG.md

@@ -0,0 +1,221 @@
+# pyinto Changelog
+
+Development changes for 0.0.1. This is not a formal release history.
+
+
+## 0.0.1 (Alpha, unpublished)
+
+Initial development setup and Construct experiments after the design shift.
+
+version: 0.0.1
+
+
+Added:
+
+
+- In Iteration 49, exposed finite Construct variant domains (`VARIANTS` / `variant_domain()`) in the Model and added registration-time rejection of invalid variant names and omitted `default` variants that do not exist. Structural projection now requires an explicit variant for multi-variant or open-domain Constructs. Added `variant @= '*'` to match any variant, exact-variant precedence, and duplicate rejection, while preserving Composition's Template/Slot chaining and Admission checks. Open variant domains such as `IntrinsicCall` remain unenumerated.
+- In Iteration 48, added Target Pack declarations `pack_semantics` (`preservation`/`projection`) and `pack_unhandled` (`error`/`traverse`) to Shikumi and the Registry. A Structural projection Target can explicitly choose `traverse` for unregistered Realizers and continue visiting descendants. Projection does not require execution-semantic `supports` checks, but Admission registration still validates the entire Model. Preservation and Composition retain their strict defaults. Added regression coverage using a non-text Target that extracts only function names and return types.
+- In Iteration 47, introduced Shikumi declarations selecting Composition or Structural Realizer dispatch per Target Pack and Target-owned Artifact Sessions. Preserved Composition's deferred Template/Slot chain; `TextArtifactSession` performs final string rendering on the Target side. Structural dispatch visits all Constructs in `Model.parts()` order, and `visit` callbacks modify Target-specific state. After dispatch, the Host calls `finish()` and receives an artifact of arbitrary type. Kept the Model, Frontend, and Admission unchanged and verified C, development-only Python, and new non-text Targets.
+- In Iteration 46, added restricted support for typed `*args` in top-level user-defined functions. Variadic `TupleType`, `ParameterRole.VARIADIC`, `FunctionSignature.variadic_parameter`, and extra positional arguments in the existing `FunctionCall` preserve default/keyword binding for fixed parameters, source-order evaluation, and tuple typing. The body can access the variadic tuple with `len`, `sum`, and `for`; Target realization of variadic tuples is an explicit new Admission obligation. Reject dynamic argument unpacking, variadic function values, nested functions/methods with variadics, and `**kwargs`. No new C Realization was added; existing Interface Mapping behavior remains.
+- In Iteration 41, added Shikumi parent/child declarations `@maps(function)` / `@signature(...)` and `factory @= ...`, and an `InterfaceMappingRegistry.from_declarations()` API that converts them to existing function Mappings. Reuses the existing routes for multiple signatures, named arguments, defaults, statically typed variadic positional arguments, and ambiguity rejection. Migrated the external Device example. Function objects are restricted to their defining module name; re-exports and class/method Mappings were not extended. Existing Frontend and Target realization contracts are unchanged.
+- As the Iteration 40 external Interface function Mapping extension, added `InterfaceVariadicParameter` for static variadic positional arguments and explicit registration of multiple signatures under one function name. Argument expressions are normalized just once regardless of candidate count; only the uniquely matching signature's factory runs, selected by type, arity, names, and defaults. Explicitly reject duplicate registrations, no match, ambiguous matches, type mismatches, dynamic argument expansion, and side-effecting argument reorderings whose evaluation order cannot be preserved. The Model, Admission, Target realization rules, and the previously accepted single-signature cases are unchanged.
+- Following Iteration 38, published `InterfaceParameter` to declare external Interface function Mapping parameters by name, value type, and trailing immutable literal default. Ordinary Python positional, keyword, and mixed calls normalize into Model arguments in declaration order. Reject unknown, duplicate, missing, type-incompatible, or unpacked arguments, and reorderings of side-effecting expressions that cannot preserve evaluation order. Retained the old positional-only Mapping acceptance, removal of `_force`, and existing Model/Target contracts.
+- Extended absolute imports in the Python Source Adapter: `import module[.submodule] [as alias]` and `from package import submodule [as alias]` in the initial import section now resolve names statically against explicitly registered external APIs. Multi-level attribute function calls normalize to the same Interface Mapping. Module name collisions, unregistered names, and dynamic attribute paths are explicitly rejected. Model semantics, C Target Realizations, and the policy of never executing Python source are unchanged.
+- In public-surface redesign step 3, added Shikumi `@naming` for declaring Target naming rules with a no-argument decorator marker. It uses the same `NAMING` information as `naming @= True` and retains class-level exclusion from `@realizes(element)` and legacy role descriptors, duplicate naming-rule rejection per Target, and the `requirement_line` Slot constraint. The C Target and development Python Realizer would migrate from legacy syntax in a later step; Model, Frontend, and Target conversion coverage did not change.
+- In public-surface redesign step 2, added Shikumi `@realizes(element)`. Public Host Constructs, direct Builtin Call element `builtin.PrintCall`, and type `ValueKind` / `PortType` use the same keys in the existing Registry routes for Constructs, Calls, and type spellings. Kept `print` Call separate from `PrintValues`, and rejected old/new duplicate registrations, invalid targets, unsupported Contracts, and invalid Slots. Existing `handles`/`binds`/`spells`/`naming`, C/Python Target implementations, and Frontend acceptance remained unchanged. `@naming`, removal of legacy descriptors, and other public Call elements were deferred.
+- In public-surface reorganization step 1, added `pyinto.interfaces.language` / `builtins` and `pyinto.model.value_types`. These re-export existing Construct classes and `ValueKind` enum with identity preserved, providing Target authors with entry points that do not expose internal file layout or string keys for types. The conversion API, Shikumi role descriptions, C Target, and the Model's semantic and acceptance/rejection contracts remain unchanged. `@realizes(element)` and `@naming` were deferred pending target-identity auditing.
+- In Model expressiveness expansion step 12 (Iteration 35), enabled statically normalized, explicitly typed new variable declarations inside `if/else`, `while/else`, `for/else`, and `with` bodies, using existing `Initialize` / `Block` (FRT_071). References are allowed only after declaration in the same or nested body, and rejected after the body, in other clauses, or before declaration.
+- In Model expressiveness expansion step 11 (Iteration 34), enabled `for` to introduce one implicit variable when the element type is known (CST_073 / FRT_070). Separated an introduction flag on `IterationEntry` from the prerequisite `iteration.binding.introduced` Admission contract and avoided artificial initialization on empty iteration. Existing iteration over previously declared variables remains valid; references from outside the loop or its `else` clause are not accepted.
+- In Model expressiveness expansion step 10 (Iteration 33), added `SliceValue` for typed lists and strings (CST_072 / FRT_069). It preserves omitted bounds, negative steps, index clipping, and the runtime error for a zero step. Shallow list copying and Unicode string selection are independently registered as semantic obligations for Admission.
+- In Model expressiveness expansion step 9 (Iteration 32), normalized `in` / `not in` for typed list elements and dictionary keys into an independent Membership Construct (CST_071 / FRT_068). Registered evaluation order, kind-specific lookup, and result negation with Construct-provider AdmissionRules.
+- In Model expressiveness expansion step 8 (Iteration 31), added fixed-length tuple unpacking assignment `UnpackAssign` into previously declared names (CST_070 / FRT_067). Registered independent contracts for exactly-once evaluation of the RHS as a whole and left-to-right updates of assignment targets; unsupported Realizations must reject it.
+- In Model expressiveness expansion step 7 (Iteration 30), added `FormattedString`, which preserves ordered pieces of f-strings without formatting specifications, and `PrintValues`, which emits zero or multiple values together (CST_069 / FRT_066). Reused existing typed `str` conversion `IntrinsicDefinition` and separated stringification and output contracts.
+- In Model expressiveness expansion step 6 (Iteration 29), extended the standard Intrinsic provider table with 15 signatures for zero-argument `str`/`int`/`float` and one-argument typed conversions among `int`/`float`/`str`/`bool`, plus Unicode `str.upper`/`str.lower` operations (CST_068 / FRT_065). Added per-signature semantic contracts and acceptance/rejection regression tests.
+- In Model expressiveness expansion step 5 (Iteration 28), made `IntrinsicRegistry` support multiple static signatures under the same operation key and added signature-local `IntrinsicTypeVar` / `IntrinsicListType` (CST_067 / FRT_064). Added unique static candidate selection; rejection of duplicate, ambiguous, type-incompatible, and unbound-type-variable cases; expression statements for methods returning `None`; and signature-specific contract and Admission regression tests.
+- In Model expressiveness expansion step 4 (Iteration 27), introduced provider-defined `IntrinsicDefinition` / `IntrinsicRegistry` with static signatures and semantic contracts, and `IntrinsicCall` preserving call evaluation order (CST_066 / FRT_063). Verified positive and negative type/arity cases, duplicate provider keys, precedence for existing declarations on name collision, call contracts, and Slots.
+- In Model expressiveness expansion step 3 (Iteration 26), introduced `IntegerTrueDivision` for true division of integers producing a float, plus five bitwise binary operations on integers, unary `~`, and augmented bitwise assignment in the Model and Frontend (CST_065 / FRT_062). Added positive and negative tests covering negative numbers, negative shift counts, arbitrary precision, and type mismatches.
+- In Model expressiveness expansion step 2 (Iteration 25), added `AugAssign` for rebinding previously declared `int`/`float` names and typed instance fields, and `ComparisonChain` for three-or-more-part comparisons among same-typed `int`/`float`/`str` operands (CST_063–064 / FRT_060–061). Added negative tests for input types/operators and regression tests for binary comparison and ordinary assignment.
+- In Model expressiveness expansion step 1 (Iteration 24), added the no-op `Pass` and static docstring metadata for `Program`, `FunctionDefinition`, and `ClassDefinition` (CST_062 / FRT_059). Updated the package Admission registry and independent audit ledger, and added positive and negative Model/Frontend tests.
+- In post-Phase-30 foundation refinement step 23, derived existing evaluation-order contracts for typed binary expressions, Port Calls, and `FunctionValueCall` from Construct-side `AdmissionRule` and rejected Realizations lacking the appropriate declaration before rendering (CMP_020). Conservatively detected missing, duplicate, or reordered Value Slots in simple Templates.
+- In post-Phase-30 foundation refinement step 22, revisited Frontend normalization and Model/Realization boundaries for keyword arguments, defaults, dataclasses, lambdas, signed constants, and future typed primitive operations in the canonical audit. Recorded the Model semantics versus Target realization distinction, unchanged contracts, and decisions deferred to future specifications.
+- Added regression tests for equivalence between dataclass and explicitly typed `__init__` Models, declaration-order binding and source-order evaluation, omitted defaults versus explicit arguments, collision avoidance for lambda internal names, and rejection of unsupported general decorators and mutable defaults. Existing semantic contracts, Target Packs, and `AdmissionRule` remain unchanged; the evaluation-order and Slot issues from step 23 remain pending.
+- In post-Phase-30 foundation refinement step 21, registered independent Construct-provider AdmissionRules for `For` with `break`/`continue` and normally completed `else`, and for `With` entry/exit including exceptional exit. Matched them to `supports` declared by standard C/Python Packs (CMP_019).
+- In post-Phase-30 foundation refinement step 20, introduced explicit Construct-provider `AdmissionDeclaration` / `AdmissionRegistry`. Distinguished contracts of the 67 concrete core Constructs from those of external Port providers and rejected unregistered Models before composition (CMP_018). Moved admission rules out of bindings to the neutral provider side and removed Target Pack self-registration of contracts.
+- In post-Phase-30 foundation refinement step 19, corrected evaluation-order contracts for five bound direct-call forms. Even positional calls in parameter order require `call.arguments.left_to_right` with at least two explicit arguments; rebinding that reorders them additionally requires `call.arguments.reordered` (CMP_017). Omitted defaults do not count as evaluated argument expressions.
+- In post-Phase-30 foundation refinement step 18, added tests mechanically linking the Model semantic-information audit to Realization admission rules. They detect missing classifications for new guard fields or non-field obligations, and missing rule registrations. Prototype forms of `IntrinsicCall`, `AugAssign`, and comparison chains tested extensions to open operation names and evaluation contracts (CMP_016).
+- In post-Phase-30 foundation refinement step 17, the Frontend checks the iteration-source type for `for` and element-type compatibility with previously declared targets. Fixed erroneous acceptance of non-iterables such as `int`, element mismatches, and dictionary iteration (FRT_003). Added checks for `supports` according to the iteration form for `IterationEntry` and `For` (CMP_015).
+- In post-Phase-30 foundation refinement step 16, added positive and negative tests for composite contracts across five direct-call forms. Rejected missing, duplicated, or evaluation-order-altering actual-argument Slots in simple string Templates before composition (CMP_014). Verified generated output of static Templates/TemplatePlans preserving source order and omitted arguments and confirmed side-effect order by executing generated Python Target code.
+- In post-Phase-30 foundation refinement step 15, introduced Target Pack `supports` declarations and contract matching after Realization selection. Mechanically extracted from Model instances obligations for function/constructor/method argument binding, nontrivial evaluation order, omitted arguments, `VIRTUAL`/`SUPER`, and class Receiver identity, rejecting undeclared obligations before rendering or requirements collection (CMP_013). Standard Target Packs without bindings for the new subjects retained their previous acceptance scope.
+- In post-Phase-30 foundation refinement step 14, classified the declared fields of all 67 Construct classes in the canonical audit ledger and added a test that finds newly added classes or fields omitted from that ledger. Enabled generating `devdocs/canonical_documents/REALIZATION_BOUNDARY_AUDIT.md` from Python canonical sources and recorded unprotected contracts and test scenarios for evaluation order, argument omission, `super`, iteration forms, short-circuiting, and other behaviors.
+- Added five tests for independent class-type reservation, shared Context among class/function/expression/statement components, `super` method calls, single application of dataclass behavior, and parse-state isolation after failure. Updated Contrace's implementation traversal to the new structure.
+- Added five regression tests for argument evaluation order in the standalone function component, nested functions/lambdas, fresh state across parses, and scope restoration on failure.
+- Added regression tests for sharing parse Context with an independent statement normalizer, function bodies containing exceptions, restoring control-flow state on failure, and recreating services between parses.
+- Added regression tests for independent expression normalization, agreement between per-parse Context and Port normalizers, expressions involving function values and lambdas, and lack of shared state after re-parsing or failure.
+- Added regression tests for the independent `PortNormalizer`, import resolution, decorator/Port alias collisions, and lack of shared state after failed parsing with a reused Frontend.
+- Added regression tests for normalizing registered external decorators into static methods, class structure, and typed function Models, and rejection of unknown handlers, signature mismatches, and repeated applications. Target Realizations and existing Model contracts are unchanged.
+- Added regression tests counting identifier generation in nested field/method/assignment paths with lambda actual arguments, and checking nested scopes and failure recovery. Model semantic contracts and Target Realization acceptance remain unchanged.
+- Added regression tests for return-type mismatches during direct Model construction, `None`/`Any`/`object`, nominal inheritance, Returns inside control statements, ownership boundaries for nested functions, and Frontend diagnostics. Existing decorator and Realization semantics are unchanged.
+- Added regression tests for value-type projection, direction of nominal inheritance, type coherence of direct/indirect calls, and Frontend acceptance. Existing Realization, decorator, and scope semantics are unchanged.
+- Added `pyproject.toml`, the MIT License, author `minoru-jp`, and a `src` layout.
+- Created Japanese canonical sources and generated documents for README, STATUS, and CHANGELOG.
+- Integrated `shikumi-devdoc` document generation with `shikumi-contrace` contract/test associations.
+- Prototyped four Construct slots, a Python AST Frontend, and C source generation.
+- Added pytest tests compiling and executing generated C.
+- Added tests for replacing Bindings, validation errors, missing registrations, and duplicate registrations.
+- Added an independent Python Target Pack, checks for Slot names, roles, and duplicate definitions, and execution tests across languages.
+- Added an exploratory external, Python-executable Port (`demo_ports`) and a separate adapter mapping it to Target-language Domain Constructs.
+- Added explicit fully qualified name registration and duplicate checks in `PortRegistry`, Python-only handling of the `_force` constant, and explicit rejection of unknown dependencies.
+- Added an external `DeviceIsReady` Construct/C Target Pack with a `device.h` requirement, plus GCC/Clang compilation, linking, and execution tests of the separate C implementation.
+- Added `shikumi-contrace` contracts for Ports and tests confirming deliberately different Python and C behaviors.
+- Added external instance Port declarations via `PortClassDefinition`, with constructor variants, explicitly registered methods/properties, and strict acceptance and rejection.
+- Added `ConstructStart` and `ExplicitCleanup` Constructs. Normal realization did not place Cleanup automatically; a registered explicit `release` call could request Cleanup for the original Construct.
+- Added separate `demo_memory_ports` and `demo_memory_ports_henkan` packages; tested Python execution of `ManualMemoryRegion.integer(minimum=..., maximum=...)` and C dynamic allocation, assignment, reading, and explicit freeing.
+- Added compact/wide Target Pack storage type selection by constraints, C compilation/execution, rejection of out-of-range/unregistered/aliased cases, and Port contract integration tests.
+- Implemented a shared Composer, final Renderer, and Shikumi rules for a single template and selection callback.
+- Implemented propagation of type spellings based on aliased Port-reference type declarations and value-range contracts.
+- Added the `While` Construct containing a condition Value, body Block, and normal-completion Block.
+- Added C/Python `while` Target Bindings and verified recursive composition and execution using the existing Composer.
+- Added Target-independent `Break`/`Continue` Constructs usable with `while ... else`.
+- Structured `For`/`IterationEntry`/`Range` and `With`/`ContextEntry`, with supported C/Python Bindings and verification tests.
+- C's `range`-based `for` Binding now evaluates arguments once, uses an independent iteration variable, and suppresses `else` after interruption.
+- Added `root`, `current`, `parent`, `ancestors`, and `path` structure references to `EmitContext` used for Binding selection. The original Construct must not be modified.
+- Added generation of `GLOSSARY.md` from shikumi-devdoc Vocabulary canonical sources, covering Model, Construct, Interface, Realization, Template, Slot, and related terms.
+- Established an initial SDD baseline by authoring Construct, Frontend, and Composition specifications via shikumi-devdoc Specification, plus an INDEX and render/synchronization checks.
+- Added reinforcing tests for current specification IDs, retaining the policy not to prematurely rename Realization components or add new Interface features.
+- Added specifications CST_007/008 and CMP_008 and Model/Realization boundary regression tests.
+- Added Conversion API clauses CVT_001–003, Composition clause CMP_009, and tests for source conversion, Target replacement, and explicit Port designation.
+- Added specifications CST_009 and CMP_010, plus tests for Model immutability, multiple range forms, and rejection of incorrectly used Slots.
+- Added specifications CST_010–012 and CMP_011 and tests for standalone Model use, reuse across Targets, and boundaries of output Slots.
+- Added specifications CST_013–014 and CMP_012, static and example-based checks of dynamic With entries, construction-time rejection, and external Construct compatibility checks.
+- In SDD Phase 7, introduced Target-independent Models for `Arithmetic`, `IntegerUnary`, `BooleanOperation`, and `BooleanNot`, plus Python Frontend expression normalization.
+- Added specifications CST_015–016 and FRT_007–008 and tests checking types, structures, evaluation order, and rejection when Target Realizations are unavailable.
+- In SDD Phase 8, added `FunctionSignature`, `Parameter`, `FunctionDefinition`, `FunctionCall`, and `Return` to the Model; the Python Frontend can normalize typed functions, explicit returns, and local scopes.
+- Specified CST_017–018 and FRT_009–010, with tests for recursion, forward references, type mismatches, isolated scopes, and rejection of unsupported Realizations.
+- In SDD Phase 9, extended Python Frontend lexical resolution to directly nested functions at arbitrary depth; `FunctionSignature.scope` and `Symbol.scope` distinguish declarations with identical names.
+- Added CST_019 and FRT_011–012 and tests for outer-variable references, same-level recursion, forward references, name shadowing, and rejection of unsupported syntax. No new Construct classes or Realizations were added.
+- In SDD Phase 10, introduced recursive `ValueType` / `CallableType` and `ValueKind.FUNCTION`, associating each function declaration's value reference with `FunctionSignature.value_symbol`.
+- Added CST_020–021 and FRT_013–014 and tests for typed function-value references, passing and returning function values, type mismatches, and indirect-call rejection. Existing `with` semantics and Realizations were unchanged.
+- In SDD Phase 11, added `FunctionValueCall` and support in the Model/Frontend for indirect positional calls through function-typed variables, arguments, and expressions returning a Callable. Direct `FunctionCall` contracts were unchanged.
+- Added CST_022 and FRT_015–016 and tests for function-value evaluation order, type consistency, multi-stage indirect calls, static closure capture paths, and rejection when Realizations are unsupported.
+- In SDD Phase 12, introduced read-only, Target-independent `henkan.analysis.lexical_captures()`. It derives each function's direct captures in first-occurrence order from existing declaration scopes and References/FunctionCalls; no dedicated Closure Construct was introduced.
+- Specified in CST_023–024 and FRT_017 the responsibility split between static captures and per-call runtime environments. Added regression tests for deep nesting, sibling-function references, function-value passing, repeated factory calls, self-recursion, and rejection of unsupported syntax.
+- In SDD Phase 13, added recursive fixed-length `TupleType` and `TupleValue` / `TupleElement`, allowing `tuple[...]` annotations, literals, nesting, and static nonnegative positional access in the Model/Frontend. Combinations with parameters, return values, and Callable types are also checked by type shape.
+- Added CST_025–026 and FRT_018–019 and tests covering element order, recursive types, bounds, invalid types, and unsupported Target Realizations. Existing `with` semantics were unchanged.
+- In SDD Phase 14, added `Raise`, `ExceptHandler`, and `Try`. Introduced static raising and type-specific catching of `ValueError`, `TypeError`, and `RuntimeError`, along with `try`/`except`/`else`/`finally` structure, to the Model/Frontend. Defined string-type requirements for raised messages and explicit rejection of unsupported exception forms.
+- Added CST_027–029 and FRT_020–021 and tests for exception clause ordering, normal completion, control transfers, `finally` precedence, non-mutation of the source Model, and rejection of unsupported Realizations. Existing `with` semantics and implementation were unchanged.
+- In SDD Phase 15, added recursive `ListType` / `ValueKind.LIST` and `ListValue`, `ListElement`, and `ListElementAssign`, bringing typed homogeneous mutable lists, dynamic integer-index reads, and type-checked element updates to the Model/Frontend.
+- Added CST_030–031 and FRT_022–023 and tests for empty/nested lists, combinations with functions, Callables and tuples, aliasing, captured references, type mismatches, and rejection of unsupported Realizations. Existing `with`, tuple, and exception semantics were unchanged.
+- In SDD Phase 16, added `DictType` / `ValueKind.DICT` and `DictEntry`, `DictValue`, `DictElement`, and `DictElementAssign`. Typed mutable `dict[int, V]` and `dict[str, V]` Models preserve ordered key/value expressions, reference sharing, replacement of existing keys, insertion of new keys, and failure on missing-key access.
+- Added CST_032–033 and FRT_024–025 and tests for recursive dictionary/list/tuple/Callable types, contextual typing of empty dictionaries, functions, closures, aliases, and explicit rejection of unsupported syntax or absent Realizations. Existing `with`, tuple, list, and exception semantics were unchanged.
+- In SDD Phase 17, added `InstanceType` / `ValueKind.INSTANCE`, `ClassSignature` / `ClassDefinition`, `FieldDefinition` / `FieldInitialize` / `FieldRead` / `FieldWrite`, and `InstanceCreation` / `MethodCall`. Reused `FunctionDefinition` for class methods and marked receivers explicitly with `ParameterRole.RECEIVER`, not merely by name or position.
+- Specified CST_034–036 and FRT_026–028. Added tests for statically declared/initialized fields, nominal typing, aliased attribute access, explicit receiver and module namespace separation, rejection of unsupported dynamic mechanisms, and absent Realizations. Existing `with` and other semantics were unchanged.
+- In SDD Phase 18, represented static single inheritance with `InstanceType.base`, `ClassSignature.base`, and hierarchical declaration references. Added virtual dispatch for ordinary method calls, lexical immediate-parent lookup for `super()`, derived-to-base compatibility, and invariants for parent initialization and overriding signatures.
+- Added CST_037–039 and FRT_029–031 with tests for multi-level inheritance, virtual calls through base types, `super` calls on the same receiver, and rejection of type mismatches or non-static inheritance. No new class Realizations were supplied; existing `with` semantics remain unchanged.
+- In SDD Phase 19, added verification of combinations of statically inherited classes with functions, first-class function values, tuples, lists, dictionaries, and closures. Typed element references and function return values can act as method receivers; calls through Callable-typed instance fields normalize to existing `FieldRead` / `FunctionValueCall`.
+- Added CST_040–041 and FRT_032–034 with 30 composition, boundary, and unsupported-Realization regression cases. No new Constructs or Target Realizations were added; existing `with` and other semantics were unchanged.
+- In SDD Phase 20, audited capabilities of the Model, Frontend, and Realization and the boundaries of unadopted syntax. Recorded priority candidates such as Boolean constants, general None values, and conditional expressions, and the next specification-review steps, in `devdocs/reviews/phase20_construct_capability_audit_ja.md`.
+- Added 37 independent tests observing accepted and rejected cases from Phase 19. Existing Construct semantics, Frontend, Target Realizations, and normative shikumi-devdoc CST/FRT specifications were unchanged.
+- In SDD Phase 22, added `Length`, `Absolute`, and `Extremum` to the Model/Frontend. Normalized built-in `len` for strings, tuples, lists, and dictionaries; `abs` and `min`/`max` with at least two arguments are restricted to integers.
+- Added CST_045–047 and FRT_039–041 and checks for types, expression evaluation order, name-resolution boundaries, and unsupported Realizations. Existing Range/Call/With, function, and collection semantics were unchanged; replaced older Phase-20 rejection tests with cases still unsupported under the new specification.
+- In SDD Phase 21, added strict Boolean constants as `BooleanLiteral`, general expression-level `NoneLiteral`, and typed `ConditionalExpression` to the Model/Frontend. Did not introduce Python truthiness or implicit Optional/Union; preserved child expression structure, type checking, and the contract not to evaluate the unchosen branch.
+- Added CST_042–044 and FRT_035–038 and tests for accepted and invalid types, combinations with functions/compound types, and explicit rejection of unsupported Realizations. Updated expectations in older unsupported-case diagnostics to current type mismatches without changing existing Literal, Return, or `with` contracts.
+- In SDD Phase 23, added `IntegerSum` and `BooleanAggregate` to the Constructs/Frontend. `sum` is restricted to integer lists/tuples/ranges with an optional integer start; `any`/`all` accept Boolean lists/tuples and define short-circuit behavior and results on empty containers.
+- Added CST_048–049 and FRT_042–044 with regression cases for evaluation order, empty containers, explicit types, name resolution, and missing Realizations. Updated an old unsupported-`sum` test and the old FRT_041 unadopted list for the new specification, preserving `with` and existing expression semantics.
+- In SDD Phase 24, added an independent floating-point value kind (`ValueKind.FLOAT` / `FloatingLiteral`), floating-point addition/subtraction/multiplication/division, signs and comparisons, and Unicode string concatenation, repetition, comparison, substring membership, and indexing to the Model/Frontend.
+- Added CST_050–055 and FRT_045–047 with 49 new verification cases. Preserved existing integer/string Literal and integer-operation behavior, `with`, numeric Interfaces, and Realization semantics; Target Realizations for the new cases remain unimplemented.
+- In SDD Phase 25, accepted static keyword actual arguments for direct `FunctionCall`, `InstanceCreation`, and ordinary/`super` `MethodCall`. Stores arguments in parameter order separately from source `evaluation_order`, exposing evaluation-order contracts for side-effecting expressions to Realizations.
+- Added CST_056 and FRT_048–049 and regression tests for named-argument binding, type matching, mixing positional/keyword arguments, rejection of duplicate/missing/unpacked arguments, existing indirect-call limits, and unsupported Realizations. Existing `with` and other semantics were unchanged.
+- In SDD Phase 26, added immutable scalar literal defaults to trailing typed parameters in `FunctionSignature` / `Parameter` and implemented static completion of omitted actual arguments for direct `FunctionCall`, `InstanceCreation`, and ordinary/`super` `MethodCall`.
+- Added CST_057 and FRT_050–051 and regression cases for explicit-argument evaluation order, distinguishing omitted positions, `NoneLiteral`, type errors, rejection of mutable defaults, unsupported indirect calls through function values, and existing structures. Did not add general Python default expressions or Target Realizations.
+- In SDD Phase 30, introduced `LambdaValue`. Typed lambda parameters and return values in an explicit Callable context, reusing `FunctionDefinition` and static lexical reference/capture structures.
+- Added CST_061 and FRT_056–057, and tests for typed lambdas, nesting, combinations with function parameters/return values and collections, rejection of insufficient type context and unadopted syntax, and missing Realizations. Existing `with`, class, and other semantics were unchanged.
+- In SDD Phases 27–29, accepted built-in `@staticmethod` / `@classmethod` and explicitly imported `@dataclass` as separate restricted features. Added `MethodKind` distinct from ordinary methods, `CLASS_RECEIVER`, `ClassMethodCall`, and `ClassReceiverCreation`, plus synthesis of dataclass initialization into existing class structures.
+- Added CST_058–060 and FRT_052–055 and regression cases for acceptance/rejection, inheritance, argument evaluation order, and defaults. Did not add general decorators, descriptors, general dataclass code generation, or Target Realizations; existing `with` and other contracts remained unchanged.
+- Reorganized the Frontend as a package, separating explicit type-annotation normalization, registration of decorator names and import-alias resolution, and common diagnostics. Added FRT_058 and internal-boundary tests. Unknown or unimplemented effects are rejected without evaluation or inference; existing Model/Realization semantics are unchanged.
+- Declared cross-domain internal operation signatures in `FrontendOperations` and consolidated mutable declaration, class, and control-flow state in `ParseContext`, initialized independently for each parse. Added tests for reparsing, isolation after failure, and module boundaries.
+- Added tests for `Symbol` value-type identity, separation of Port types, and receiver constraints. No backward-compatibility layer was provided for the old `Symbol` constructor; refinements to Realization contract selection and argument evaluation order were deferred.
+
+Changed:
+
+
+- In Iteration 50, moved the validation C Target from the planned independent `targets/c` distribution to `tests/support/c_realizer`, alongside the Python Realizer as non-distributed Host reference implementations. Migrated C-dependent tests, Contrace, examples, and development settings; prohibited reverse Host-to-C imports and audited that the C Realizer depends only on public Host APIs. Preserved C Composition, Admission, generation, and rejection behavior and consolidated wheel distribution into the Host alone. Earlier experiments with an independent C wheel remain part of the history.
+- In Iteration 45, extended Iteration 44's explicit `global` writes to existing typed module variables to `AugAssign` for `int`/`float`. Preserved original module `Symbol` identity and contracts for evaluating the target once, reading before the RHS, and rebinding. Included `AugAssign` in function-local name precollection, fixing the mistaken interpretation of `counter += 1` without `global` as a module write. The Model, Admission, and Targets were unchanged; unsupported Realizations still reject.
+- In Iteration 44, the Python Source Adapter began accepting limited references and simple reassignment of typed module variables through an initial `global` statement. It requires typed module declarations preceding the function and maps them to existing `Assign` while preserving the original `Symbol.scope` and identity. Rejects later/unknown/Port names, collisions, non-initial or control-body declarations, nested functions/methods, `nonlocal`, augmented assignments, and `for` targets. No Model/Target Constructs or Realizations changed; preserving shared-state semantics remains the Target's responsibility.
+- In Iteration 43, standardized dynamic type-spelling Selectors to two arguments `(shape, spell)`. `spell` recursively invokes registered type spellings of the same Target and explicitly rejects unregistered inner types, invalid results, or cycles. Migrated Port-type Selectors and the memory-Port example while retaining fixed type names, Target separation, and Model type semantics.
+- In Iteration 42, passed the complete `ValueType`/`PortType` shapes held by the Model to Realization type-spelling Selectors. Added a `return_type` Slot to `FunctionDefinition` and unified its type-rendering route with `Parameter`, `Initialize`, and `FieldDefinition`. For tuple-type Slots, added per-Slot separator specification through `separators @=`, retaining default newline layout, explicit rejection of unknown types and inline multiline results, and existing Target output. Model type semantics and Frontend acceptance did not change.
+- In public-surface redesign step 5, standardized Target declarations on `@realizes(element)` and `@naming`. Removed legacy `handles`/`binds`/`spells` information types, assignment descriptors, and Registry branches, and compatibility for `naming @= True`. Updated tests, demos, and current canonical specifications while preserving ordinary conversion, contract checking, and explicit rejection. Generic public elements for external direct Calls were not implemented.
+- In public-surface redesign step 4, migrated every declaration in the independent C Target and private development Python Realizer to `@realizes(element)` / `@naming`. Compared registration results and generation/rejection behavior before and after migration for 17+24 Construct registrations, direct `print` Call, three primitive C types, variants, and naming rules. Legacy Host compatibility for `handles`/`binds`/`spells`/`naming @= True`, semantic contracts, and Frontend acceptance remained.
+- In Iteration 36 migration step 8, re-audited the public/distribution boundary between Host and C Target. Excluded development-only Contrace contract modules inadvertently bundled in the Host wheel while retaining source-side development tests. Added regressions for distribution names, dependency versions, and explicit Realization selection. Installed the two independent wheels in separate environments and tested C generation, compilation/execution, and unsupported-Construct rejection. Model semantics and Frontend acceptance stayed the same.
+- In Iteration 36 migration step 7, revised README, GLOSSARY, STATUS, and current specification terminology to match the implemented structure. Clarified ownership among Model/Interface/Construct, the Host/Target Implementation split, and Python Interface Mapping versus Model type information. Historical changelog and audit terminology was kept; implementation, semantics, and acceptance/rejection did not change.
+- In Iteration 36 migration step 6, moved former Python Target rules from `src/pyinto/targets/python/` to `tests/support/python_realizer/` as a private development Realizer. Updated tests and Contrace and excluded it from the Host wheel. Surface APIs, language semantics, and realization coverage were unchanged; no new guarantee of type preservation or perfect Python round-tripping was made.
+- In Iteration 36 migration step 5, moved the C Language Implementation to `targets/c/src/pyinto_target_c/` in the same repository to clarify its distribution dependency boundary with the Host. Removed the C Target re-export from `pyinto.realizations.c` and switched to explicitly supplying `pyinto_target_c.c_bindings()`. Added independent C distribution settings and dependency-direction tests, preserving C generation, rejection contracts, and Model normalization. Separate-repository migration and development Python Realizer cleanup were deferred.
+- In Iteration 36 migration step 4c, renamed external Python API mapping to `pyinto.interface_mapping`, `InterfaceMappingRegistry`, and related names. `convert()` / `PythonFrontend` now use the `interface_mappings=` argument. Preserved modeling, Admission, and rejection for registered functions/classes/methods/attributes. Type-related `PortType`, `ValueKind.PORT_OBJECT`, and `port:` keys were deferred, retaining names specific to external sample libraries.
+- In Iteration 36 migration step 4b, renamed realization-rule registration to `RealizationRegistry` and moved `pyinto.bindings/` to `pyinto.realizations/`. Placed Template/Slot/Layout/Renderer under `realizations.layout`, standardized the public conversion argument to `realizations=`, and context references to `registry`. Retained Target factory names such as `c_bindings()` and Shikumi's `binds` because they serve different purposes, preserving success/rejection paths and semantic contracts.
+- In Iteration 36 migration step 4a, renamed the standard language-structure contract ledger from `CORE_ADMISSION` to `LANGUAGE_ADMISSION` and its listed names to `LANGUAGE_CONSTRUCT_NAMES`. Renamed `AdmissionRegistry.require_core()` to `require_baseline()` to avoid restricting the operation to a particular Interface. Default registrations, extension policy, rejection of removals/replacements, and unknown-Construct rejection stayed unchanged.
+- In Iteration 36 migration step 3, renamed distribution/import namespaces and sample/test Adapter packages from `henkan` to `pyinto`. Retained old `BindingRegistry`, `PortRegistry`, `CORE_ADMISSION`, and Target Pack internal APIs, and unchanged semantic and acceptance/rejection contracts.
+- Continue to reject Port rebinding or declarations inside control bodies, newly bound names directly under `try`/`except`/`finally`, and lambda captures of new control-local or implicit `for` variables. Retain function/module ownership of Symbols and existing Realizations. Conclude Model expressiveness expansion for now and prioritize Python Pack realization/semantic-preservation verification in the next stage.
+- Reject mixed/empty tuples with ambiguous types, implicit type determination for unknown Iterables, and introduction of reserved names. Do not add corresponding Realizations to standard Python/C Packs; existing iteration and control-flow contracts remain unchanged.
+- Preserve single-index access. Reject dictionary/tuple slices, mismatched types, and undeclared names. Add Model positive/negative tests and contract audits, but no standard Target Pack recipes.
+- Preserve the old `StringContains` for string membership, rejecting searches of incompatible types, non-collections, or membership inside comparison chains. Add Model-only positive and negative tests, not new Target Pack recipes.
+- Verify rejection of mismatched tuple positional types/lengths and undeclared, nested, or starred targets, while regression-testing swaps and duplicate destinations. Keep the extension Model-first without adding standard Python/C Pack rules.
+- Retain the old Call for single-string `print`; extended printing requires the new Construct's Admission rule. Do not add Python/C Target Pack recipes and reject `!r`/`!a`, format specifications, keyword arguments, or arbitrary-object stringification.
+- Set `PythonFrontend`'s default `IntrinsicRegistry` to the standard table above. An explicitly supplied `intrinsics` still replaces the entire default table, which can be explicitly extended using `standard_intrinsics().extend(...)`. Existing dedicated Constructs such as `Length`, the Model's `IntrinsicCall`, and Python/C Target Packs are unchanged. Runtime conversion errors, float string representations, and Unicode case mapping remain unimplemented Realization contracts; a `supports` declaration alone does not prove preservation.
+- `IntrinsicCall` keeps its resolved concrete static signature; operation-series variants are not subdivided by type. Matching candidates does not re-normalize expressions, infer types, perform implicit conversions, or select Realizations. Default Intrinsic tables and standard Python/C Pack acceptance remain unchanged.
+- Initially keep the default Intrinsic table empty; only explicitly registered non-conflicting operations are recognized via `PythonFrontend(intrinsics=...)` / `convert(intrinsics=...)`. Added operation-name and once-only/evaluation-order obligations for receivers and arguments to Construct-provider Admission. Did not extend standard Python/C Packs, dedicated existing built-in Constructs, general inference, dynamic attributes, or overloads.
+- Registered true-division numerical contracts and contracts for infinite-sign-extension bitwise semantics and shift counts in Construct-provider `AdmissionRule`, along with evaluation-order obligations. Do not import Target-specific widths or shift rules into the Model, or change C/Python standard Pack realization coverage. Updated the audit ledger and Japanese canonical source.
+- Registered once-only target evaluation, read-before-RHS and rebinding, plus comparison-chain intermediate-value once-only evaluation, short-circuiting, and order with Construct-provider `AdmissionRule`; updated the audit ledger. Both remain Model-first with no new Python/C recipes; neither `supports` declarations nor generated code are asserted to constitute a general proof of semantic preservation.
+- Treat only the leading string constant as a docstring, distinct from executable expressions. Retain static class-field rules, restricted dataclasses, and inherited-constructor constraints. Target Pack and Realization admission coverage is unchanged.
+- Standard C `Comparison` conservatively rejects complex operands whose evaluation order C cannot guarantee, retaining comparisons of simple references and integer literals. Standard Python `Comparison` explicitly registers `supports`. Do not put Target-specific ordering in the Model; preservation by TemplatePlans and generated code remains subject to individual execution tests.
+- Without changing Model structure or Frontend acceptance for `For`/`With`, added Target execution tests for C `range` iteration and Python `for`/`with`. Comparison operand evaluation order remains explicitly pending for step 23.
+- Reject overriding baseline rules, unregistered derived Constructs, and unregistered children omitted by Templates. Pass explicit Admission to `realize` and contracts through `PortRegistry` to `convert`. Port demo providers declare independent Constructs, and missing `supports` is rejected before rendering. Existing pending contracts, desugaring, Model types, and Model semantics are unchanged.
+- Without adding Target-specific execution ordering to the Model, enforced existing Model ordering obligations as prechecks for Realizations. Added negative tests modeling Targets that cannot guarantee evaluation order and a canonical-document-based audit plan for boundaries/desugaring. Textual Slot ordering alone does not prove Target execution order. Migration of external Construct contract ownership, pending standard Pack coverage, and changes to desugared forms were deferred.
+- Consolidated extraction of required contracts into `AdmissionRule` declarations. Adding admission rules to `BindingRegistry` retains standard rules, and undeclared support is still rejected before rendering. Short-circuiting, `finally`, and environment lifetimes remain explicitly unprotected; Model and Frontend syntax acceptance is unchanged.
+- Retained Target-neutral `For` Models, including non-Range iteration. Standard C Pack covers `range` only, while standard Python Pack outputs `range`, string, list, tuple, and general Iterable loops; `supports` alone does not guarantee semantic preservation.
+- Does not automatically prove arbitrary Realization semantic preservation: derivation of dynamic `TemplatePlan`, evaluation order within recipes, and concrete `super` calls need separate execution verification. Model/Frontend acceptance and standard Target Pack coverage are unchanged.
+- The field audit in step 14 remains a non-normative ledger; admission matching does not imply coverage of every audited contract. `supports` is an author's capability declaration, not proof of correct Target execution. Enforcement for iteration, `finally`, short-circuiting, closures, and similar semantics remains incomplete.
+- In post-Phase-30 foundation refinement step 13, moved class normalization from `ClassNormalization` Mixin to an independent `ClassNormalizer` with typed `ClassServices` dependencies. Normalizers are independent objects for each parse, obsolete `FrontendOperations` stub base was removed, and cross-component operations go through `PythonFrontend` delegation entry points. Existing semantic contracts and Realizations were unchanged.
+- In post-Phase-30 foundation refinement step 12, moved function declarations, calls, lambdas, and lexical resolution from Mixins to `FunctionNormalizer`. Limited `FunctionServices` to needed cross-domain operations and linked classes/statements/expressions via `PythonFrontend` delegation. Parse Context and decorator registration remain shared per parse. Existing semantics and Realizations were unchanged.
+- In post-Phase-30 foundation refinement step 11, moved statement, control-flow, and exception normalization to an independent `StatementNormalizer`; narrowed `StatementServices` to the other operations needed. `PythonFrontend` now delegates Block/statement entry points. Existing syntax acceptance/rejection and Model/Realization contracts were preserved.
+- In post-Phase-30 foundation refinement step 10, moved expression normalization from `PythonFrontend` multiple inheritance into `ExpressionNormalizer`, making required name/function/class operations explicit in `ExpressionServices`. Clarified responsibilities with per-parse sharing of `ParseContext` and Port normalizer and centralized state recreation. Other Mixins and existing semantics/Realizations were untouched.
+- In post-Phase-30 foundation refinement step 9, moved Port expression/declaration normalization from a Frontend Mixin into an independent `PortNormalizer`, which receives only typed value/scope references and `ParseContext`, inheriting no other normalizer methods. Split explicit imports for type names, Ports, and decorators into `ImportNormalizer`, clarifying per-parse lifetimes. Existing acceptance/rejection and Model/Realization semantics were unchanged.
+- In post-Phase-30 foundation refinement step 8, extended `DecoratorRegistry` with registration of class/method/function effect-normalization handlers. Migrated the existing three decorators to the mechanism and reused class extension plans between collection and construction. Retained rejection of unregistered effects; did not add general Python decorator execution or multi-stage application.
+- In post-Phase-30 foundation refinement step 7, passed instance-expression receivers downstream as already-normalized Values, eliminating duplicate normalization in field reads/writes and method calls. Unified save/restore of normal-function and lambda state in `ParseContext.callable_scope`, making scope lifetimes explicit even on failure.
+- In post-Phase-30 foundation refinement step 6, began checking owned Returns against declared return types when constructing `FunctionDefinition`, including Returns in branches, loops, With, and Try. Nested functions are checked separately, with no control-flow reachability inference. Simplified Frontend ordinary-return and lambda type checking to use shared `assignable`.
+- In post-Phase-30 foundation refinement step 5, derived structural Value type shape exclusively from `value_type`, removing five redundant type-shape forwarding properties. Made `assignable` explicit in type rules and aligned derived-instance arguments accepted by `FunctionValueCall` with direct calls. Typed collections and Callables retain strict equality.
+- In post-Phase-30 foundation refinement step 4, unified `FunctionSignature.return_type` and Frontend type annotations around `ValueType`. Removed scattered return-type fields and the seven-element annotation tuple; separated Port annotations from normal value types. Existing semantic contracts and Realizations were unchanged.
+- Put aside the original plan to define a bespoke notation from the outset and changed direction to construct Constructs from ordinary Python code.
+- Removed C-specific snippet generation from Constructs and moved it to replaceable Language Bindings validated by Shikumi declarations.
+- Split Shikumi rule definitions, registration, and snippet realization into named modules, and added the Target Pack declaration format.
+- Moved C code-generation rules to `targets/c/pack.py`, still retaining recursive composition inside Constructs at that stage.
+- Enabled collection of `requires` declared on Constructs in a Target Pack into the generation context and their application to Program.
+- Reduced excessive parentheses in C comparison snippets so equality comparisons compile even under strict Clang warnings.
+- Following design decision 12, made the Frontend require type annotations on all new variable definitions.
+- Following design decision 13, removed the fixed four-slot Construct design (emit, Snippets, AAA+Cleanup) and switched to pure structure and deferred Template/Slot composition.
+- Rewrote the Python and C Target Packs and external Port adapters for the new approach.
+- Implemented Port release as an explicit operation Construct, not a Cleanup Slot request.
+- Reworked pytest and Shikumi-Contrace contracts comprehensively for the new realization model.
+- Extended Frontend, Contrace, and pytest to check typed `while` conditions, nesting, `else`, and rejection of unsupported syntax.
+- Changed C's `while ... else` Binding into a `for` expansion with interruption detection, verifying normal completion with `break` and `continue`.
+- Added new structure and realization contracts to Shikumi-Contrace. Maintained the policy of not generating English published documents at that development stage.
+- Fixed Composer Slot composition order to first occurrence within the Template and reinitialized header/auxiliary-name generation state per composition request.
+- Renamed the public project and Python import name to `henkan` and updated examples, contracts, and tests.
+- In SDD Phase 2, removed `Named`/`Layout` helper-type dependencies from `Construct.parts()`, replacing them with pure Model components such as `Identifier`, `Symbol`, and tuples.
+- Moved separators between multiple `with` entries into Python Target realization rules and separated output requirements into a reserved Composer-side Slot.
+- In SDD Phase 3, removed `Program.to_source()` / `to_c()` and unified conversion entry points under `henkan.convert()` / `realize()`.
+- Migrated tests, examples, and Contrace from `ProgramPort` to an independent `CompositionPort`, removing Model dependence on Realization.
+- In SDD Phase 4, removed range-specific projection from `For.parts()` and made the C range Binding provide extra Slots through `TemplatePlan`.
+- In SDD Phase 5, removed the Program required-header Slot from Model `HOLES` and treated it as a Program-specific output Slot validated by Shikumi declarations.
+- Reject non-`int`/`str` Literal values at construction time, clarifying the Target-independent Model value domain.
+- In SDD Phase 6, redefined `HOLES` as names of possible Model components of a Construct, not existing Slots, and changed static component validation to `accepts_part_name()`.
+- Changed Model type/operator invariant checks for `Comparison`, `Initialize`, `Assign`, `Branch`, and `While` from `parts()` access time to construction time.
+- Updated FRT_014 and Phase-10 indirect-call rejection tests when new separate indirect-call contracts were added; corrected two malformed tuple descriptions in historical test data.
+- Began post-Phase-30 module reorganization by splitting Constructs into types, base, values, type rules, collections, operations, control, functions, and classes. Updated single-file AST checks and Contrace implementation traversal to cover each definition module.
+- In post-Phase-30 module reorganization step 2, split the large `frontend/parser.py` rules into classes, functions, statements, expressions, and ports; the parser handles the parse entry point and connects imports/type annotations.
+- Configured Contrace to traverse new Frontend definition modules while retaining existing acceptance/rejection rules and Model/Realization semantic contracts. No public API compatibility aliases or English published documents were added at that point.
+- In module reorganization step 3, changed `Symbol` type information to a single stored field holding `ValueType`, `PortType`, or `None`. Distinguished ordinary values from Port/built-in declarations, made old type categories and composite shapes derived properties, and reduced redundant type-checking and signature construction.
+
+Removed:
+
+
+- Removed the earlier limited Branch v0 (Python/Rust source generation), along with its tests and contracts.
+- Removed the old `ConstructStart` / `ExplicitCleanup` and Snippets/four-stage declarations dependent on AAA+Cleanup.

pyinto-0.0.1/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 minoru-jp
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

pyinto-0.0.1/MANIFEST.in

@@ -0,0 +1,2 @@
+include README.md STATUS.md CHANGELOG.md LICENSE
+recursive-include docs *.md

pyinto-0.0.1/PKG-INFO

@@ -0,0 +1,127 @@
+Metadata-Version: 2.4
+Name: pyinto
+Version: 0.0.1
+Summary: Experimental Python-to-Model normalization and target-defined artifact realization
+Author: minoru-jp
+License-Expression: MIT
+Classifier: Development Status :: 3 - Alpha
+Classifier: Intended Audience :: Developers
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
+Classifier: Topic :: Software Development :: Libraries :: Python Modules
+Requires-Python: >=3.11
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Requires-Dist: shikumi>=0.2.4
+Provides-Extra: dev
+Requires-Dist: shikumi==0.2.4; extra == "dev"
+Requires-Dist: shikumi-devdoc==0.3.5; extra == "dev"
+Requires-Dist: shikumi-contrace==0.1.0; extra == "dev"
+Requires-Dist: pytest<10,>=8; extra == "dev"
+Requires-Dist: ruff==0.16.10; extra == "dev"
+Requires-Dist: basedpyright==1.40.1; extra == "dev"
+Dynamic: license-file
+
+# pyinto
+
+**pyinto is a Host library that normalizes typed Python code into a Target-independent Model and lets Target Implementations realize that Model as a wide range of artifacts.**
+
+## ⚠️ Development status
+
+pyinto is an **experimental Alpha-stage library**. Its APIs, Model, specifications, and design are subject to change. **Breaking changes may be introduced without advance notice or a migration period.** Compatibility between releases is not guaranteed. Use caution before deploying it to production or adopting it as a long-term dependency. See [STATUS](STATUS.md) for the current implementation status.
+
+## Installation
+
+Requires Python 3.11 or later.
+
+```bash
+pip install pyinto
+```
+
+## Conceptual model
+
+pyinto models the structure and semantics obtained from Python independently of any particular output format. A Target Implementation uses that Model to produce an artifact.
+
+```text
+              Typed Python Source
+                       │
+                       ▼
+              ┌─────────────────┐
+              │   pyinto Host   │
+              │                 │
+              │    Frontend     │
+              │       ↓         │
+              │ Construct Model │
+              │       ↓         │
+              │    Admission    │
+              │       ↓         │
+              │    Dispatch     │
+              └────────┬────────┘
+                       │
+                       ▼
+              ┌─────────────────┐
+              │     Target      │
+              │ Implementation  │
+              │                 │
+              │  Realizations   │
+              │       ↓         │
+              │ Artifact State  │
+              │       ↓         │
+              │  Finalization   │
+              └────────┬────────┘
+                       │
+                       ▼
+                    Artifact
+```
+
+**The Host constructs the Model and controls Realization dispatch. The Target Implementation constructs and submits the artifact.**
+
+## Host responsibilities
+
+The pyinto Host provides:
+
+- **Frontend:** statically analyzes typed Python and normalizes it into the Model.
+- **Construct Model:** represents program structure and meaning without tying them to a Target.
+- **Admission:** checks contracts governing the Model and its Realizations.
+- **Realization Dispatch:** invokes Realizers according to the Model structure and the declared dispatch mode.
+
+The Host does not prescribe an artifact format or internal representation.
+
+## Target Implementation responsibilities
+
+A Target Implementation consumes Model information supplied by the Host. It defines Realizations, manages generation state, constructs its artifacts, and submits the final result.
+
+Translation into other programming languages remains a primary use case, **but there is no Host-imposed restriction on the form of the artifact**. A Target may produce structured data, diagrams, documentation, analysis reports, images, executable files or other **binary files**. An artifact need not even be a file: it may be any object the Target chooses to return.
+
+A Target also chooses whether it aims to **preserve** execution semantics or **project** selected information from the Model.
+
+## Realization dispatch modes
+
+**Composition** recursively connects Realizations via Template/Slot references. It is particularly useful for constructing structured text, including source code. **Structural** walks the Model structure and invokes matching Realizers, making it suitable for information extraction, structural analysis, diagrams, and structured data. In both modes, the Target Implementation owns the final artifact.
+
+## Target Implementations
+
+**pyinto distributes the Host library only. It does not ship any concrete Target Implementation.** Installing pyinto alone therefore does not enable conversion into C or any other programming language. You must provide a suitable Target Implementation separately.
+
+Target authors can use pyinto's public Model, Realization, Admission, and related interfaces. The repository includes development-only Python and C reference Realizers under `tests/support/`; these are test assets, not part of the pyinto distribution.
+
+Start with the **[Target Implementation Guide](docs/target_implementation/INDEX.md)** for design choices, declarations, Constructs and variants, semantic contracts, artifact generation, and verification. The guide is structured with LLM-assisted implementation work in mind.
+
+## Documentation
+
+| Document | Purpose |
+| --- | --- |
+| [STATUS](STATUS.md) | Current development state, supported features, and limitations |
+| [Target Implementation Guide](docs/target_implementation/INDEX.md) | Implementing Target Implementations |
+| [Specification](docs/specification/INDEX.md) | Normative behavior and contracts |
+| [Glossary](docs/GLOSSARY.md) | Project terminology |
+| [Changelog](CHANGELOG.md) | Development history |
+
+Japanese canonical sources and generated Japanese documents are maintained in `devdocs/`. English documents here are published derivatives, not independent normative sources. [Translation coverage](docs/TRANSLATION_STATUS.md) identifies which long-form specifications are currently abridged; consult the Japanese canonical documents for complete conditions.
+
+## License
+
+See [LICENSE](LICENSE).

pyinto-0.0.1/README.md

@@ -0,0 +1,100 @@
+# pyinto
+
+**pyinto is a Host library that normalizes typed Python code into a Target-independent Model and lets Target Implementations realize that Model as a wide range of artifacts.**
+
+## ⚠️ Development status
+
+pyinto is an **experimental Alpha-stage library**. Its APIs, Model, specifications, and design are subject to change. **Breaking changes may be introduced without advance notice or a migration period.** Compatibility between releases is not guaranteed. Use caution before deploying it to production or adopting it as a long-term dependency. See [STATUS](STATUS.md) for the current implementation status.
+
+## Installation
+
+Requires Python 3.11 or later.
+
+```bash
+pip install pyinto
+```
+
+## Conceptual model
+
+pyinto models the structure and semantics obtained from Python independently of any particular output format. A Target Implementation uses that Model to produce an artifact.
+
+```text
+              Typed Python Source
+                       │
+                       ▼
+              ┌─────────────────┐
+              │   pyinto Host   │
+              │                 │
+              │    Frontend     │
+              │       ↓         │
+              │ Construct Model │
+              │       ↓         │
+              │    Admission    │
+              │       ↓         │
+              │    Dispatch     │
+              └────────┬────────┘
+                       │
+                       ▼
+              ┌─────────────────┐
+              │     Target      │
+              │ Implementation  │
+              │                 │
+              │  Realizations   │
+              │       ↓         │
+              │ Artifact State  │
+              │       ↓         │
+              │  Finalization   │
+              └────────┬────────┘
+                       │
+                       ▼
+                    Artifact
+```
+
+**The Host constructs the Model and controls Realization dispatch. The Target Implementation constructs and submits the artifact.**
+
+## Host responsibilities
+
+The pyinto Host provides:
+
+- **Frontend:** statically analyzes typed Python and normalizes it into the Model.
+- **Construct Model:** represents program structure and meaning without tying them to a Target.
+- **Admission:** checks contracts governing the Model and its Realizations.
+- **Realization Dispatch:** invokes Realizers according to the Model structure and the declared dispatch mode.
+
+The Host does not prescribe an artifact format or internal representation.
+
+## Target Implementation responsibilities
+
+A Target Implementation consumes Model information supplied by the Host. It defines Realizations, manages generation state, constructs its artifacts, and submits the final result.
+
+Translation into other programming languages remains a primary use case, **but there is no Host-imposed restriction on the form of the artifact**. A Target may produce structured data, diagrams, documentation, analysis reports, images, executable files or other **binary files**. An artifact need not even be a file: it may be any object the Target chooses to return.
+
+A Target also chooses whether it aims to **preserve** execution semantics or **project** selected information from the Model.
+
+## Realization dispatch modes
+
+**Composition** recursively connects Realizations via Template/Slot references. It is particularly useful for constructing structured text, including source code. **Structural** walks the Model structure and invokes matching Realizers, making it suitable for information extraction, structural analysis, diagrams, and structured data. In both modes, the Target Implementation owns the final artifact.
+
+## Target Implementations
+
+**pyinto distributes the Host library only. It does not ship any concrete Target Implementation.** Installing pyinto alone therefore does not enable conversion into C or any other programming language. You must provide a suitable Target Implementation separately.
+
+Target authors can use pyinto's public Model, Realization, Admission, and related interfaces. The repository includes development-only Python and C reference Realizers under `tests/support/`; these are test assets, not part of the pyinto distribution.
+
+Start with the **[Target Implementation Guide](docs/target_implementation/INDEX.md)** for design choices, declarations, Constructs and variants, semantic contracts, artifact generation, and verification. The guide is structured with LLM-assisted implementation work in mind.
+
+## Documentation
+
+| Document | Purpose |
+| --- | --- |
+| [STATUS](STATUS.md) | Current development state, supported features, and limitations |
+| [Target Implementation Guide](docs/target_implementation/INDEX.md) | Implementing Target Implementations |
+| [Specification](docs/specification/INDEX.md) | Normative behavior and contracts |
+| [Glossary](docs/GLOSSARY.md) | Project terminology |
+| [Changelog](CHANGELOG.md) | Development history |
+
+Japanese canonical sources and generated Japanese documents are maintained in `devdocs/`. English documents here are published derivatives, not independent normative sources. [Translation coverage](docs/TRANSLATION_STATUS.md) identifies which long-form specifications are currently abridged; consult the Japanese canonical documents for complete conditions.
+
+## License
+
+See [LICENSE](LICENSE).