Skip to content

Productize Samsarix Routine Engine and add its Samsarix roadmap #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Deathcharge merged 2 commits into from
Jul 29, 2026
Merged

Productize Samsarix Routine Engine and add its Samsarix roadmap #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
41f9359
Productize Samsarix Routine Engine
Deathcharge Jul 29, 2026
e542bcd
docs: add Samsarix product roadmap
Deathcharge Jul 29, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 51 additions & 0 deletions .github/workflows/ci.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
name: CI

on:
push:
pull_request:
workflow_dispatch:

permissions:
contents: read

jobs:
quality:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4

@coderabbitai coderabbitai Bot Jul 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win

Set persist-credentials: false on both checkout steps.

actions/checkout writes the job token into .git/config by default, so any later step (or uploaded artifact containing .git) can leak it. Neither job pushes, so credentials are not needed.

🔒️ Proposed hardening 
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v4
+        with:
+          persist-credentials: false

Apply the same change to the test job checkout at Line 44.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
- uses: actions/checkout@v4
- uses: actions/checkout@v4
with:
persist-credentials: false
🧰 Tools
🪛 zizmor (1.28.0)

[warning] 15-15: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false

(artipacked)

[error] 15-15: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)

(unpinned-uses)

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/ci.yml at line 15, Update both checkout steps in the test
and build jobs to set persist-credentials to false, ensuring the checkout action
does not retain the job token in the repository configuration.

Source: Linters/SAST tools

- uses: actions/setup-python@v5
with:
python-version: "3.13"
cache: pip
- run: python -m pip install --upgrade pip
- run: python -m pip install -e ".[dev]"
- run: ruff check .
- run: ruff format --check .
- run: mypy src
- run: pytest --cov --cov-report=term-missing
- run: python -m build
- run: python -m twine check dist/*
- name: Verify wheel contents and installed CLI
shell: bash
run: |
python -m venv /tmp/routine-wheel
/tmp/routine-wheel/bin/python -m pip install dist/*.whl
/tmp/routine-wheel/bin/python -c "from routine_engine import RoutineEngine; print(RoutineEngine)"
/tmp/routine-wheel/bin/routine-engine demo --name CI

test:
runs-on: ${{ matrix.os }}
strategy:
fail-fast: false
matrix:
os: [ubuntu-latest, windows-latest]
python-version: ["3.10", "3.11", "3.12", "3.13"]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: ${{ matrix.python-version }}
cache: pip
- run: python -m pip install --upgrade pip
- run: python -m pip install -e ".[dev]"
- run: pytest
6 changes: 6 additions & 0 deletions .gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,3 +30,9 @@ venv.bak/
*.swo
*~
.DS_Store
.coverage
.pytest_cache/
.mypy_cache/
.ruff_cache/
htmlcov/
.venv-*/
24 changes: 24 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
# Changelog

All notable changes will be documented here. The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); the project does not claim semantic-version stability before 1.0.

## [Unreleased]

### Changed

- Reframed the repository as Samsarix Routine Engine, a focused local-first Python workflow component.
- Updated the existing BSL licensor, licensed-work identity, copyright, and licensing contact for Samsarix LLC without changing its production threshold, change date, or change license.
- Isolated the supported product under `src/routine_engine`; archived Helix-era source is excluded from wheels.
- Replaced aspirational and inaccurate documentation with the implemented contract and release gates.
- Hardened archived filesystem containment and changed legacy authorization to fail closed; legacy code and network actions are disabled.

### Added

- Validated acyclic workflow and step models with explicit resource limits.
- Trusted sync/async action registration, bounded concurrency/retries, references, and exact terminal results.
- Atomic local JSON workflow/run persistence with bounded history.
- `routine-engine` CLI for validation, execution, explicit plugins, and a built-in demo.
- Behavioral unit/integration tests, coverage gate, linting, typing, package checks, wheel smoke test, and CI matrix.
- Productization decision record, security policy, API guide, and runnable examples.

[Unreleased]: https://github.com/Deathcharge/routine-engine/compare/v0.1.0...HEAD
3 changes: 2 additions & 1 deletion CODE_OF_CONDUCT.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,8 @@ We are committed to providing a welcoming, inclusive, and harassment-free enviro

## Reporting

Report unacceptable behavior to the maintainers.
Report unacceptable behavior to [support@samsarix.com](mailto:support@samsarix.com). Samsarix LLC will review reports as privately as practical.


## Enforcement

Expand Down
53 changes: 18 additions & 35 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,48 +1,31 @@
# Contributing to Routine Engine
# Contributing to Samsarix Routine Engine

We welcome contributions! Here's how to get started.
Thank you for helping keep Routine Engine small, dependable, and honest.

## Getting Started

1. Fork the repository
2. Clone your fork
3. Create a branch: `git checkout -b feature/your-feature`
4. Make changes and commit: `git commit -am 'Add feature'`
5. Push to branch: `git push origin feature/your-feature`
6. Submit a pull request

## Development Setup
## Setup

```bash
git clone https://github.com/YOUR_USERNAME/routine-engine.git
git clone https://github.com/Deathcharge/routine-engine.git
cd routine-engine
pip install -e ".[dev]"
pip install -r requirements-test.txt
python -m venv .venv
.venv/Scripts/python -m pip install -e ".[dev]"
```

## Running Tests
Use `.venv/bin/python` on macOS or Linux.

## Required checks

```bash
pytest tests/ -v
pytest tests/ --cov
ruff check .
ruff format --check .
mypy src
pytest --cov --cov-report=term-missing
python -m build
python -m twine check dist/*
```

## Coding Standards

- Follow PEP 8
- Use type hints
- Write comprehensive docstrings
- Minimum 80% test coverage
- Keep lines under 100 characters

## Pull Request Process

1. Ensure all tests pass
2. Add tests for new functionality
3. Update documentation
4. Provide clear description
5. Wait for review
Pull requests should add behavioral tests, update user-facing docs when the contract changes, and avoid expanding the focused scope without a written product rationale. The coverage floor is 90%; new critical paths should be covered regardless of the aggregate number.

## Code of Conduct
Do not add actions that execute workflow-supplied code, commands, paths, SQL, URLs, or provider calls to the built-in set. Application integrations belong behind explicit registration.

Please follow our [Code of Conduct](CODE_OF_CONDUCT.md).
Report security concerns privately to [support@samsarix.com](mailto:support@samsarix.com), not in a public issue.
14 changes: 7 additions & 7 deletions LICENSE
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,24 +5,24 @@ License text copyright (c) 2020 MariaDB plc, All Rights Reserved.

Parameters

Licensor: Helix Collective
Licensed Work: Helix Licensing System
The Licensed Work is (c) 2024 Helix Collective
Licensor: Samsarix LLC
Licensed Work: Samsarix Routine Engine
The Licensed Work is (c) 2026 Samsarix LLC
Additional Use Grant: None

Change Date: June 16, 2027

Change License: Apache License, Version 2.0

For information about alternative licensing arrangements for the Licensed Work,
please contact licensing@helixcollective.dev
please contact contact@samsarix.com

Notice

Business Source License 1.1

This Business Source License (this "Agreement") sets forth the terms and conditions
under which Helix Collective ("Licensor") makes available certain software made
under which Samsarix LLC ("Licensor") makes available certain software made
available by Licensor under this Agreement (the "Licensed Work"). BY INSTALLING,
COPYING, CONFIGURING, ACCESSING, OR USING THE LICENSED WORK, YOU AGREE THAT YOU
HAVE READ, UNDERSTOOD, AND AGREE TO BE BOUND BY ALL OF THE TERMS AND CONDITIONS
Expand All @@ -45,7 +45,7 @@ the output of which is used for commercial advantage or to generate monetary rev
If, at any time (including at the time of initial deployment of production use),
the monthly volume of such production use exceeds 1,000 API calls or equivalent
usage metric, then you must secure a commercial license key from Licensor or pay
the fees specified in the pricing schedule at https://helixcollective.dev/pricing.
the fees specified in the pricing schedule provided by Licensor.

@coderabbitai coderabbitai Bot Jul 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== LICENSE excerpt and structure =="
if [ -f LICENSE ]; then
  wc -l LICENSE
  sed -n '1,120p' LICENSE | cat -n
else
  fd -a '^LICENSE$' .
fi

echo
echo "== Repository references to pricing schedule / Additional Use Grant =="
rg -n --hidden --glob '!/.git/**' --glob '!/node_modules/**' \
  'Additional Use Grant|pricing schedule|production use|BSL|License' . || true

echo
echo "== File diff stat/name-only if available =="
git diff --stat -- LICENSE 2>/dev/null || true
git show --stat -- LICENSE 2>/dev/null | sed -n '1,80p' || true

Repository: Deathcharge/routine-engine

Length of output: 9795

🌐 Web query:

MariaDB Business Source License 1.1 Additional Use Grant production use license text

💡 Result:

The Business Source License (BSL) 1.1 does not contain a single, universal "Additional Use Grant" text [1][2]. Instead, the Additional Use Grant is a placeholder section that the licensor must define for each specific product [3][4][5]. The core BSL 1.1 license text describes this section as follows: "The Licensor may make an Additional Use Grant, above, permitting limited production use." [1][2][6] In the license header or associated license file, the licensor is required to: "To either: (a) specify an additional grant of rights to use that does not impose any additional restriction on the right granted in this License, as the Additional Use Grant; or (b) insert the text 'None'." [1][2][6] Because this section is product-specific, its content varies depending on how the software vendor chooses to define their usage terms [4][5]. For example, in MariaDB Corporation’s use of the BSL for MaxScale, the Additional Use Grant has been defined as: "Additional Use Grant: You may use the Licensed Work when your application uses the Licensed Work with a total of less than three server instances in production." [7][8] In summary, if you are evaluating a BSL 1.1 licensed product, you must look at the specific license file provided with that software to find the actual text of the Additional Use Grant, as it determines the specific parameters under which you are permitted to use the software in production without a separate commercial license [4][5].

Citations:

🌐 Web query:

SPDX BUSL-1.1 BSL template SourceUseLimitation Additional Use Grant

💡 Result:

The Business Source License 1.1 (identified by the SPDX short identifier BUSL-1.1) is a source-available license that balances commercial protection for licensors with a guarantee of eventual open-source status [1][2][3]. It is not an open-source license, as it restricts production use [2][4]. The license operates as a template requiring the licensor to complete specific fields [5][3]. Central to its structure are three key components: 1. Additional Use Grant: This optional field allows the licensor to grant specific permissions that override the default prohibition on production use [2][3]. Licensors can define specific permitted use cases here (e.g., non-commercial use, internal use, or specific integrations) [6][7][8]. If no grant is provided, the licensor may simply insert "None" [5][9][10]. 2. Change Date: The licensor must specify a date or time period, capped at four years, after which the software automatically converts to the Change License [1][2][4]. 3. Change License: The licensor must specify an open-source license (which must be compatible with GPL v2.0 or later) that the software will adopt once the Change Date is reached [5][2][4]. The license explicitly grants users the right to copy, modify, create derivative works, and redistribute the software, provided they comply with the restrictions on production use as defined by the Additional Use Grant [1][5][8]. If a user's intended use falls outside the scope of the Additional Use Grant, they must purchase a separate commercial license from the copyright holder [1][2][3].

Citations:

Publish or embed the pricing schedule referenced by BSL Section 2.

Additional Use Grant: None means the only production-use terms are the Section 2 modifications, but line 48 refers to a pricing schedule that is not attached or versioned here. Make the full commercial-license terms immediately available with the distributed license or reference a stable, versioned schedule; otherwise downstream users cannot determine compliance or cost.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@LICENSE` at line 48, Update the LICENSE terms around the pricing-schedule
reference so the complete commercial pricing schedule is included with the
distributed license or replaced with a stable, versioned reference. Ensure
downstream users can determine applicable compliance requirements and fees
without relying on an unavailable document.


3. Failure to pay required fees does not relieve you of your obligation to pay such
fees. If you do not pay the required fees, Licensor may, at its sole discretion,
Expand Down Expand Up @@ -95,4 +95,4 @@ constitutes the entire agreement between the parties with respect to the subject
matter hereof and supersedes all prior negotiations, representations, and agreements,
whether written or oral, relating to such subject matter.

For commercial licensing inquiries, please contact: licensing@helixcollective.dev
For commercial licensing inquiries, please contact: contact@samsarix.com
Loading
Loading