v0.3.26 StratiDECK

Stratimux v0.3.26: StratiDECK Complete Architecture

🎯 Major Release: v0.3.26 delivers the complete StratiDECK architecture with comprehensive refinements for production-ready compositional programming.

The Design Intent Realized

v0.3.26 represents Day Two of Stratimux - the moment when the framework's architectural vision becomes reality through the complete StratiDECK system, refined and hardened for production use.

Problems Solved

Core Limitations Addressed

• Semaphore limitations: All qualities of same type previously shared identical semaphores, limiting comparisons to within concept
• No concept individualization: playerCounter.add() and sessionCounter.add() were indistinguishable
• Single origin constraint: Could only have one source per quality type

The Identity Solution

• Simple function comparators: c.playerScore.add(action) - just a function call
• Unique identities: Same quality patterns, different identities per concept instance
• Cross-concept distinction: Multiple counters/timers with individual identities

StratiDECK: Complete Architecture

🎯 The DECK Interface System

A revolutionary approach to concept composition with zero imports needed:

// Complete access through deck interface
{
  d: {              // Decks of concepts
    counter: {      // Nested concept access
      d: {...},     // Sub-concepts
      e: {...},     // Actions
      c: {...},     // Comparators
      k: {...}      // Selectors
    }
  },
  e: {...},         // Root actions
  c: {...},         // Root comparators
  k: {...}          // Root selectors
}

🔒 Production-Hardened Type System

• Complete muxified parts handling: All components properly resolve through the type system
• Complex composition support: Deep nesting maintains proper type inference
• Full TypeScript inference: Type safety across all boundaries

🚀 Enhanced Selector Architecture

Strategic naming for clarity and namespace management:

// Clear, intentional naming
k.getState()      // Retrieve current state
k.getName()       // Get concept name
k.getConcept<C>() // Type-safe concept access

🔧 Refined Developer Experience

Quality-of-Life Features

• Debug improvements: lastStrategyActionList automatically stored without overhead
• Stage composition: New createStages helper for scoped planning
• Clean console output: No debug logs in production builds
• Enhanced error handling: Better development tooling

Architectural Requirements

• Concept-Listen pairing: Enforced consistency in concept definitions
• Type flexibility: nextA accepts AnyAction without casting
• Proper citations: Muxified concept principle interfaces correctly referenced

Higher Order Composition Principle

Proven: All complex concepts are compositions of simpler concepts

• Reuse concept patterns (Counter, Timer, Toggle) across different muxified concepts
• Maintain unique identities through the DECK interface system
• Build sophisticated applications from proven building blocks

Key Features

Concept Portability

• True reusability with identity preservation
• Pattern sharing across concept boundaries
• Type-safe composition at any depth

Scalable Complexity

• Compositional architecture: Complexity through composition, not complication
• Effective mapping: Distinguish between same quality types
• Proven patterns: Build on tested foundations

Developer Productivity

• No import overhead: Direct deck access
• Intuitive naming: Self-documenting APIs
• Compile-time safety: Catch errors early

Breaking Changes

Selector Naming Updates

To support advanced muxified concept composition:

// Previous (pre-v0.3.6)
k.state()
k.name()
k.create()

// Current (v0.3.6)
k.getState()
k.getName()
k.getConcept()

Concept Definition Requirements

Concept names and listen names must now be explicitly paired in concept load configurations.

Updated Documentation

• STRATIMUX-REFERENCE.md: Optimized for agentic workflows
• Type documentation: Complete coverage of muxified principles
• Architectural patterns: Best practices and examples

Architectural Impact

1. Foundational completion enables Stratimux's designed potential
2. Iron-clad reliability through systematic refinements
3. Production readiness with performance optimizations
4. Future-proof design supporting unlimited composition

Summary

Stratimux v0.3.6 delivers the complete StratiDECK architecture—a revolutionary approach to compositional programming that solves fundamental limitations in state management and concept composition. Through systematic refinements from v0.3.22 through v0.3.26, the framework has evolved into a production-ready system that maintains unique identities across shared patterns while providing complete type safety.

This release transforms Stratimux from technical framework to complete architectural paradigm, ready for building sophisticated applications through proven compositional patterns.

Version Progression Included

• v0.3.22: Initial StratiDECK implementation
• v0.3.24-v0.3.241: Selector architecture refinement
• v0.3.242: Production console cleanup
• v0.3.251: Concept-listen pairing enforcement
• v0.3.252: Principle type flexibility
• v0.3.253-v0.3.26: Complete type system coverage

Welcome to Day Two of compositional programming with Stratimux.

Full Changelog: v0.3.22...v0.3.26

v0.3.22 Stratideck

Stratimux v0.3.2 Stratideck - Complete Release Summary

Overview

Purpose: This release brings Full Isolated Functional Composition of Concepts into Stratimux through the new Deck System, completing the framework architecture. The system is now considered complete but can always be refined.

3.22 Hotfix

Restored Deck Parity when Concepts are Muxified to maintain proper Stratideck Routing.

Major Release Components

1. QOL 0.3.01 - Default Store Last ActionStrategy ActionList

Interface Changes

• New MuxiumState Property: lastStrategyActionList: Array<string>
• Enhanced State Interface: Added automatic storage of action lists without performance overhead

Code Example

export type MuxiumState = {
  dialog: string;
  storeDialog: boolean;
  lastStrategy: string;
+ lastStrategyActionList: Array<string>;  // NEW: Debug enhancement
  lastStrategyData: unknown;
  lastStrategyDialog: string;
  generation: number;
}

Type System Impact

• Updated Action to AnyAction in strategy creation
• Enhanced debugging capabilities without storeDialog performance cost

---

2. QOL 0.3.11 - createStages Helper Function

Interface Changes

• New Planner Interface: Added staging: typeof createStages<Q, C, S>
• Enhanced Stage Composition: Scope encapsulation with type safety

Code Example

export type Planner<Q = void, C = void, S = void> = (uI: HInterface<Q, C, S> & {
  stage: typeof createStage<Q, C, S>
  stageO: typeof stageWaitForOpenThenIterate,
  conclude: typeof stageConclude,
+ staging: typeof createStages<Q, C, S>  // NEW: Scoped composition
}) => PartialStaging<Q, C, S>[];

Usage Pattern

const muxPlan = plan<MUXDeck>('muX Plan', ({staging, stageO, stage, d__}) => staging(() => {
  const stageRegister = stageO(() => (d__.muxium.e.muxiumRegisterStagePlanner({conceptName: muXName, stagePlanner: muxPlan})))
  const stageDispatch = stage(({concepts, dispatch, k, d}) => {
    // Enhanced readability vs one-liners
  }, {beat: 30});
  return [stageRegister, stageDispatch, stageFinalize];
}));

---

3. Stratideck #258 - Complete Type System Transformation

CRITICAL BREAKING CHANGE: Quality Type System Overhaul

Problem Addressed: TypeScript's type system breaks down when concepts acquire enough qualities, necessitating explicit type definitions despite increased boilerplate.

Before (Broken at Scale)

// OLD: Simple but breaks with complexity
const qualities = { counterAdd, counterSubtract };
export type CounterQualities = typeof qualities;

After (Required for Type Safety)

// NEW: Explicit types required for stability  
export type CounterAdd = Quality<CounterState>;
export type CounterSubtract = Quality<CounterState>;
export type CounterQualities = {
  counterAdd: CounterAdd,
  counterSubtract: CounterSubtract,
};

Major Interface Changes

1. All Quality Files Now Export Types

// Every quality file requires:
+ export type [QualityName] = Quality<StateType, PayloadType?>;

2. All Concept Files Rewritten

// OLD pattern
- export type ConceptQualities = typeof conceptQualities;

// NEW pattern (REQUIRED)
+ export type ConceptQualities = {
+   qualityOne: QualityOneType,
+   qualityTwo: QualityTwoType,
+   // ... explicit mapping required
+ };

3. Muxium Type System Changes

// Signature changes throughout core system
- export function muxification<C extends LoadConcepts, Q = void>(
+ export function muxification<C extends LoadConcepts>(
// All Q generic parameters replaced with MaybeEnhancedMuxiumQualities

4. Test Pattern Updates

// ALL tests now require explicit type definitions
const qualities = {experimentDebounceNextActionNode};
+ type Qualities = {experimentDebounceNextActionNode: ExperimentDebounceNextActionNode};
const experiment = createExperimentConcept(initialState, qualities) as Concept<typeof initialState, Qualities>;

Boilerplate Analysis

Critical Understanding: Why Abstraction Requires More Boilerplate

The documentation explicitly notes: "Even though the abstraction adds more boilerplate, it becomes necessary regardless after a concept acquires enough qualities - TypeScript starts to break down in its typings."

Boilerplate Impact by Numbers

• 91 files changed (+4,189 lines added, -969 removed)
• Every quality: +1-2 lines for type exports
• Every concept: Complete type interface rewrite
• Every test: Explicit type definitions required
• Core system: Major signature changes throughout

Trade-off Justification

1. Scale Requirement: Complex concepts with many qualities broke TypeScript
2. Type Safety: Explicit typing ensures reliability at enterprise scale
3. Development Experience: Better IDE support and error catching
4. Framework Completion: Enables the full DECK interface system

The Complete StratiDECK System

Achievement: Full Isolated Functional Composition

The v0.3.21 release completes the Stratimux vision by providing:

1. StratiDECK Interface System: No longer need to import actions, selectors, or prime semaphores
2. Entry Points:
   • d - Access to all loaded decks
   • e - Entry point for actions
   • c - Semaphore comparator functions
   • k - Constant selectors
3. Type Safety: Complete type coverage through explicit interfaces
4. Functional Composition: True isolation of concept functionality

Code Pattern Evolution

// FINAL PATTERN: Complete type safety with DECK access
type DECK = {
  counter: Concept<CounterState, CounterQualities>,
  experiment: Concept<ExperimentState, ExperimentQualities>
}

const muxium = muxification<DECK>('MyApp', {
  counter: createCounterConcept(),
  experiment: createExperimentConcept(state, qualities)
});

// Usage with full type safety and DECK interface
muxium.plan<DECK>('MyPlan', ({stage, d}) => [
  stage(({dispatch, d}) => {
    dispatch(d.counter.e.counterAdd()); // Full type inference
  })
]);

Migration Impact

Breaking Changes Summary

1. All quality files: Must export explicit types
2. All concept files: Quality type interfaces must be rewritten
3. All consuming code: Must use explicit type definitions
4. Package name: Changed from @phuire/stratimux to stratimux

Developer Impact

• Learning curve: Understanding explicit type patterns
• Maintenance overhead: More type definitions to maintain
• Benefit: Type safety at scale, better IDE support, framework completion
• Future-proofing: System now handles complex higher order composition of concepts.

Conclusion

Stratimux v0.3.22 represents the completion of the framework's core architecture. While requiring more explicit boilerplate, this release ensures type safety and functionality at enterprise scale. The DECK system now provides full isolated functional composition, making Stratimux a complete solution for complex asynchronous graph programming needs.

The key insight: Abstraction simplicity must sometimes give way to explicit complexity when the type system demands it for reliability and scale.

Stratimux 0.3.0: Precision & Performance

Stratimux 0.3.0: Precision & Performance

This release offers key improvements to Stratimux, enhancing both functionality and stability.

✨ Features & Enhancements

• Forward Capability Implementation ([PR #251](#251)): Introduces significant quality-of-life improvements related to forward capability, allowing the system to better handle future states and transitions in asynchronous processing.

• Deck Usage Standardization ([PR #242](#242)): Improves consistency in how Decks function throughout the application, creating more predictable patterns for data structure interactions.

🐛 Bug Fixes

• Dialog Functionality Restored ([PR #245](#245)): Resolves issues affecting dialog functionality, ensuring proper communication between system components.

• Bad Action Handling Improved ([PR #246](#246)): Fixes the handling of unexpected actions, strengthening system resilience during complex operations.

🛠️ Maintenance & Refinements

• Node.js Workflow Update ([PR #238](#238)): Enhanced CI/CD pipeline compatibility and efficiency.

• Jest-C Removal ([PR #243](#243)): Streamlined testing setup by removing an unnecessary testing component.

• Documentation Improvements ([PR #240](#240)): Updated README on npmjs for clearer user and contributor information.

🚀 Release Status

Version 0.3.0 is officially tagged and released ([PR #252](#252)).

Full Changelog: v0.2.0...v0.3.0

Minor QoL

Incremental Update

• Properly allow for Decks to be passed now to all Method Creators
• Cleaned up code base to ease with separation of concerns.
• strategy export -> strata

What's Changed

• Update node.js.yml by @REllEK-IO in #238
• Refinement by @REllEK-IO in #237
• Refinement by @REllEK-IO in #239
• Updated readme on npmjs by @REllEK-IO in #240
• Refinement by @REllEK-IO in #241

Full Changelog: v0.2.0...v0.2.4

STEALTH 0.2.0 DECK INTERFACE UPDATE

Essentially a complete refactor of interfaces, but not core functionality.

More information to come.

Consistency Update

Consistency Update

Focused on improving the internal consistency of Stratimux with this release. Breaking only action creator functions to fold into the options design pattern that is used throughout. This is not only a quality of life update, but a strong fighting position for Stratimux. That will the reinforcement of axiumTimeOut, we can now see a Function as an Operating System (FaaOS) Paradigm truly take shape.

Updates moving forward will be focusing on expanding the capabilities of Stratimux, versus just ensuring a rock solid computation environment. These will focus on decomposing certain aspects of the Axium into their own concepts. So that those parts may have their own dedicated qualities that can be unified into your own concepts. The strongest contenders for this are the Strategy, Dialog, and Unified Subject(Stage Planner).

For example unifying some Strategy Concept into your working set. Would append the lastStrategy and lastStrategyData properties to your concepts properties. The only downside to this change is having to create specific steps in strategies to handle the setting of these values. Versus the Axium internally handling these properties themselves.

The downside of further decomposition, is increasing the total skill cap when utilizing Stratimux. What we have now is a very fine MVP, but beyond this point. Will require tutorials, developer tools, etc... To reduce the complexity of learning how to work in this new paradigm.

Cheers~
Have Fun~

v0.1.72

• Added a new Axium Quality: axiumRegisterTimeOut, that accepts an action and specified timeout that will run the axiumTimeOut function then succeed an incoming strategy if present.
  • This likewise fulfills the original purpose of buffer, even in a complex scenario.

v0.1.71 5/16/2024

• Finally removed the need to add "as Subject | UnifiedSubject" when creating methods that access state or concepts.
• Added then removed a new Buffer Method Creator Series. See branch Stash-Buffer for details.

v0.1.69 5/15/2024

• Added priority to axium strategies.
• Improved consistency of logic due the above change.
• Exported isAxiumOpen helper function.

Strategy Priority v0.1.68 5/15/2024

• Added priority to strategies, this priority will be assigned to each step issued by such.
  • With this change you may now have strategies jump all lines upon creation, ensuring some change prior to other action's taking effect.
  • Unless a ActionNode or incoming Action created by createActionNode has its own priority, then that takes precedents. But does not effect the Strategy's overall priority.

BREAKING v0.1.67 5/13/2024

• Revamped the Action Creator Functions to follow behind the current creator with an options parameter design choice.
  • Note pure action creators will not provide an option for payload
• Cascaded priority to ActionStrategies to allow for planning priority ahead of time.
• Updated the PrincipleFunction documentation to have the semaphore parameter to now be conceptSemaphore. This allows for an easy drop in into the options parameter.
• Made createAxium utilize the same options design pattern.

v0.1.65 5/13/2024

• Removed one more level of deepness from DotPath(6 levels now), projects should now compile without the excessively deep error.

v0.1.64 5/13/2024

• Added Action Priority: This will allow action's assigned a priority of not 0 to be placed accordingly into the action ques.
• Adjusted DotPath type to improve type checking performance. Massively degrades with an additional level.
• Updated documentation to reflect recent changes

What's Changed

• Restored DotPath by @REllEK-IO in #214
• Consistency v0.1.64 by @REllEK-IO in #215
• Patch v0.1.65 by @REllEK-IO in #216
• v0.1.66 by @REllEK-IO in #217
• v0.1.67 by @REllEK-IO in #218
• v0.1.67 by @REllEK-IO in #219
• Strategy Priority v0.1.68 by @REllEK-IO in #220
• Refinement by @REllEK-IO in #221
• v0.1.69 by @REllEK-IO in #222
• Consistency by @REllEK-IO in #223
• v0.1.70 Addendum Complexity RIPS Buffer by @REllEK-IO in #224
• Removed Buffer v0.1.71 by @REllEK-IO in #225
• True Consistency Update v0.1.72 by @REllEK-IO in #226

Full Changelog: v0.1.62...v0.1.72

Strong Fast v0.1.62

Strong Fast with Lock Step Timing

This release moves closer to towards being agnostic towards NodeJS, as the purpose of this project is to demonstrate a Strong Fast Computation Algorithm. That opens a path towards realizing a such all the way down to the hardware and beyond. Specifically we have reduced the total dependency on setTimeout() via axiumTimeOut and have created a new Action Que (axium.head,body,tail) handling system to ensure a lock step operation of outcomes.

The primary difference between this version of Stratimux and one that is completely responsible for its parts. Would be the utilization of a Timing Axium, that can go further by defining a new unit of Time allowing for greater granular control. Noting that during the development of the Stage Delimiter feature the original goal was to limit an action overflow over a period of time. With the current time provided in computing, we cannot accurately predict and control the flow of actions just by timing alone. Noting the dumb limiter via some 5 consecutive actions unless a throttle: 0 is provided in the dispatch options. This would be a prime example of Stratimux even in its earliest of stages of development hitting the limits of modern computing.

BREAKING Strong Fast Lock Step v0.1.62

• Devised a means to ensure a lock step execution of incoming actions
  • Due to each stage being ran once regardless of their selector being changed, some plans may receive the wrong value if not determining if that stage has been ran for the first time. See priority.test.ts for the example: if (changes.length > 0) {//}
  • This also impacted the axiumWaitForOpenThenIterate helper function, but now works as intended via no longer checking for the latest lastStrategy change.
  • Note Removed CI checks for 14.x and 16.x due to updating dependencies.

Strong Fast Time v0.1.61

• Created the new axiumTimeOut helper function
  • This will add a specified action to the axium tail property after some specified time.
  • This is used internally to handle the majority of asynchronous interactions

Strong Fast BREAKING v0.1.59 5/06/24

• Removed the setTimeout trick in favor of a new tail property added to the axium concept, this paves the way for this pattern to be completely responsible for its own implementation.
  • BREAKING Method Subjects are now a tuple of [action: Action, async: Boolean]. This allows for the old setTimeout trick to be used in case the action stream isn't kicked into gear.
    • This change is only breaking if you have implemented your own custom methods, please see src/model/method.ts for reference.
• Ensured that plans that conclude with an active beat, will have their timers removed.

v0.1.58 Stage Flow

Stage Flow Release

Expanded and iron sided stage options to control when and how stages are informed of new observations of internal state changes.

v0.1.58 5/03/24

• Ensured that changes that happen between a stage's beat interval are accumulated

v0.1.57 5/02/24

• Added the ability to set specific stages of their selectors, priority, and beat values.
• Note that by setting these values, this will not force the internal priority selector cache mechanism to trigger. Use set for stages your are iterating to or changing due to some circumstance. The new stage options will force the priority selector cache to trigger.
• Quick pass updating the StagePlanner documentation in regards to stage selectors/priority/beat properties.

v0.1.56 5/01/24

• May now properly update each plans intended KeyedSelectors to control when they are ran.

What's Changed

• Huirth by @REllEK-IO in #204
• Dx by @REllEK-IO in #205
• v0.1.57 by @REllEK-IO in #206
• v0.1.58 by @REllEK-IO in #207

Full Changelog: v0.1.55...v0.1.58

Developer Experience v0.1.55

v0.1.54 4/24/24

• Changed ActionNodeOptions to allow for successNode and failureNode to be left absent. Continued effort towards decreasing boilerplate.
• Refined original paper.
• Properly exporting the new ActionCreator and ActionCreatorWithPayload for specific createQualitySetX creator functions

Full Changelog: v0.1.53...v0.1.55

Developer Experience v0.1.53

v0.1.53 4/23/24

• Added createQualitySet and createQualitySetWithPayload to reduce some boilerplate.

v0.1.52 Patch 4/03/24

• Quick pass updating documentation
• Synced up createAxium, etc... To properly allow for the axium to log actions incoming in the action stream if set.

BREAKING Update v0.1.5 4/02/24

• Unified the internal concept streams and created a new dedicated stream to inform most recent concepts
  • Note if you are assembling plans within a method, be sure to grab the concepts$ from getAxiumState
• It is now a requirement you use the stageWaitForOpenThenIterate(() => action) helper function in your plans if you are depending on the last strategyTopic property on the axium concept.
• Added an addition logging property to reveal the internal action stream that can be set when creating your axium. This is separate from the prior logging feature.
• Method now utilize an internal actionConcept$ stream of type Subject. Method creators that utilize the UnifiedSubject will throw a type error and will need to be updated.
• PATCH v0.1.51 Removed debugging console.logs

What's Changed

• Carousel by @REllEK-IO in #189
• Investigating bug, all configurations evaluate with no change by @REllEK-IO in #190
• v0.1.5 by @REllEK-IO in #191

What's Changed

• Patch v0.1.51 by @REllEK-IO in #192
• v0.1.52 Patch by @REllEK-IO in #193
• v0.1.52 Patch by @REllEK-IO in #194
• Dx by @REllEK-IO in #195
• Function as Operating System by @REllEK-IO in #196
• Stratimux Assistant added to repository by @REllEK-IO in #197
• Asynchronous Graph Programming by @REllEK-IO in #198
• Dx by @REllEK-IO in #199
• createQualitySet/+WithPayload by @REllEK-IO in #200

Full Changelog: v0.1.5...v0.1.53