tessellum 0.0.1__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,218 @@
1
+ # Byte-compiled / optimized / DLL files
2
+ __pycache__/
3
+ *.py[codz]
4
+ *$py.class
5
+
6
+ # C extensions
7
+ *.so
8
+
9
+ # Distribution / packaging
10
+ .Python
11
+ build/
12
+ develop-eggs/
13
+ dist/
14
+ downloads/
15
+ eggs/
16
+ .eggs/
17
+ lib/
18
+ lib64/
19
+ parts/
20
+ sdist/
21
+ var/
22
+ wheels/
23
+ share/python-wheels/
24
+ *.egg-info/
25
+ .installed.cfg
26
+ *.egg
27
+ MANIFEST
28
+
29
+ # PyInstaller
30
+ # Usually these files are written by a python script from a template
31
+ # before PyInstaller builds the exe, so as to inject date/other infos into it.
32
+ *.manifest
33
+ *.spec
34
+
35
+ # Installer logs
36
+ pip-log.txt
37
+ pip-delete-this-directory.txt
38
+
39
+ # Unit test / coverage reports
40
+ htmlcov/
41
+ .tox/
42
+ .nox/
43
+ .coverage
44
+ .coverage.*
45
+ .cache
46
+ nosetests.xml
47
+ coverage.xml
48
+ *.cover
49
+ *.py.cover
50
+ .hypothesis/
51
+ .pytest_cache/
52
+ cover/
53
+
54
+ # Translations
55
+ *.mo
56
+ *.pot
57
+
58
+ # Django stuff:
59
+ *.log
60
+ local_settings.py
61
+ db.sqlite3
62
+ db.sqlite3-journal
63
+
64
+ # Flask stuff:
65
+ instance/
66
+ .webassets-cache
67
+
68
+ # Scrapy stuff:
69
+ .scrapy
70
+
71
+ # Sphinx documentation
72
+ docs/_build/
73
+
74
+ # PyBuilder
75
+ .pybuilder/
76
+ target/
77
+
78
+ # Jupyter Notebook
79
+ .ipynb_checkpoints
80
+
81
+ # IPython
82
+ profile_default/
83
+ ipython_config.py
84
+
85
+ # pyenv
86
+ # For a library or package, you might want to ignore these files since the code is
87
+ # intended to run in multiple environments; otherwise, check them in:
88
+ # .python-version
89
+
90
+ # pipenv
91
+ # According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
92
+ # However, in case of collaboration, if having platform-specific dependencies or dependencies
93
+ # having no cross-platform support, pipenv may install dependencies that don't work, or not
94
+ # install all needed dependencies.
95
+ # Pipfile.lock
96
+
97
+ # UV
98
+ # Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
99
+ # This is especially recommended for binary packages to ensure reproducibility, and is more
100
+ # commonly ignored for libraries.
101
+ # uv.lock
102
+
103
+ # poetry
104
+ # Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
105
+ # This is especially recommended for binary packages to ensure reproducibility, and is more
106
+ # commonly ignored for libraries.
107
+ # https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
108
+ # poetry.lock
109
+ # poetry.toml
110
+
111
+ # pdm
112
+ # Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
113
+ # pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
114
+ # https://pdm-project.org/en/latest/usage/project/#working-with-version-control
115
+ # pdm.lock
116
+ # pdm.toml
117
+ .pdm-python
118
+ .pdm-build/
119
+
120
+ # pixi
121
+ # Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
122
+ # pixi.lock
123
+ # Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
124
+ # in the .venv directory. It is recommended not to include this directory in version control.
125
+ .pixi
126
+
127
+ # PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
128
+ __pypackages__/
129
+
130
+ # Celery stuff
131
+ celerybeat-schedule
132
+ celerybeat.pid
133
+
134
+ # Redis
135
+ *.rdb
136
+ *.aof
137
+ *.pid
138
+
139
+ # RabbitMQ
140
+ mnesia/
141
+ rabbitmq/
142
+ rabbitmq-data/
143
+
144
+ # ActiveMQ
145
+ activemq-data/
146
+
147
+ # SageMath parsed files
148
+ *.sage.py
149
+
150
+ # Environments
151
+ .env
152
+ .envrc
153
+ .venv
154
+ env/
155
+ venv/
156
+ ENV/
157
+ env.bak/
158
+ venv.bak/
159
+
160
+ # Spyder project settings
161
+ .spyderproject
162
+ .spyproject
163
+
164
+ # Rope project settings
165
+ .ropeproject
166
+
167
+ # mkdocs documentation
168
+ /site
169
+
170
+ # mypy
171
+ .mypy_cache/
172
+ .dmypy.json
173
+ dmypy.json
174
+
175
+ # Pyre type checker
176
+ .pyre/
177
+
178
+ # pytype static type analyzer
179
+ .pytype/
180
+
181
+ # Cython debug symbols
182
+ cython_debug/
183
+
184
+ # PyCharm
185
+ # JetBrains specific template is maintained in a separate JetBrains.gitignore that can
186
+ # be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
187
+ # and can be added to the global gitignore or merged into this file. For a more nuclear
188
+ # option (not recommended) you can uncomment the following to ignore the entire idea folder.
189
+ # .idea/
190
+
191
+ # Abstra
192
+ # Abstra is an AI-powered process automation framework.
193
+ # Ignore directories containing user credentials, local state, and settings.
194
+ # Learn more at https://abstra.io/docs
195
+ .abstra/
196
+
197
+ # Visual Studio Code
198
+ # Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore
199
+ # that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
200
+ # and can be added to the global gitignore or merged into this file. However, if you prefer,
201
+ # you could uncomment the following to ignore the entire vscode folder
202
+ # .vscode/
203
+ # Temporary file for partial code execution
204
+ tempCodeRunnerFile.py
205
+
206
+ # Ruff stuff:
207
+ .ruff_cache/
208
+
209
+ # PyPI configuration file
210
+ .pypirc
211
+
212
+ # Marimo
213
+ marimo/_static/
214
+ marimo/_lsp/
215
+ __marimo__/
216
+
217
+ # Streamlit
218
+ .streamlit/secrets.toml
@@ -0,0 +1,36 @@
1
+ # Changelog
2
+
3
+ All notable changes to Tessellum are documented here. The format is loosely [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and the project follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
4
+
5
+ ## [Unreleased]
6
+
7
+ ### Planned for v0.1.0 — Public Beta
8
+
9
+ - Engine port from parent project (composer + retrieval primitives + format validators)
10
+ - 20 essential skills (capture / search / answer / trail management / maintenance)
11
+ - 8 BB-type example notes (one per Building Block)
12
+ - Conceptual primer term notes (Z + PARA + BB + Epistemic Function + DKS + CQRS)
13
+ - Public-facing how-to library (getting-started, note-format, agent-integration, growing a trail)
14
+ - MCP server exposing v0.1 skills as tools
15
+ - CI workflow (ruff + pytest + format/link validators)
16
+ - `tessellum init` CLI for vault scaffolding
17
+
18
+ ## [0.0.1] — 2026-05-09
19
+
20
+ ### Added — Namespace Reservation
21
+
22
+ - Repository skeleton with target layout (no `src/` dumping ground; clean separation of code / vault / inbox / data / experiments / scripts / tests)
23
+ - `pyproject.toml` declaring the `tessellum` PyPI package with dependencies for the v0.1 engine port
24
+ - Top-level `src/tessellum/__init__.py` documenting the six-pillar thesis
25
+ - `src/tessellum/format/building_blocks.py` — typed Python registry of the 8 BB types, 4 epistemic layers, and 10 directed edges; the load-bearing primitive of the typed substrate
26
+ - `vault/0_entry_points/entry_master_toc.md` — Master TOC entry for the dogfooded vault
27
+ - `vault/resources/term_dictionary/term_building_block.md` — first conceptual primer term note
28
+ - README + LICENSE (MIT) + CONTRIBUTING + DEVELOPING + this CHANGELOG
29
+ - `.gitignore` for derived artifacts (`data/`, `experiments/`, build outputs)
30
+
31
+ ### Architecture decision
32
+
33
+ Tessellum dogfoods itself: the project's public documentation lives in `vault/` as typed atomic notes, not in a separate `docs/` directory. See [DEVELOPING.md § Layout Convention](DEVELOPING.md#layout-convention).
34
+
35
+ [Unreleased]: https://github.com/TianpeiLuke/Tessellum/compare/v0.0.1...HEAD
36
+ [0.0.1]: https://github.com/TianpeiLuke/Tessellum/releases/tag/v0.0.1
@@ -0,0 +1,119 @@
1
+ # Contributing to Tessellum
2
+
3
+ Thank you for considering a contribution. Tessellum is in early alpha (v0.0.1) and the contribution surfaces are deliberately limited until v0.1 ships. Read this guide before opening a PR.
4
+
5
+ ## Quick Decision Tree
6
+
7
+ | What are you contributing? | Where it goes |
8
+ |---|---|
9
+ | New skill (capture / digest / analyze) | Canonical body in `vault/resources/skills/`; thin headers in `.claude/skills/` + `.kiro/skills/`; pipeline sidecar in `vault/resources/skills/skill_<name>.pipeline.yaml` if applicable |
10
+ | New BB sub-kind (e.g., `note_second_category=spreadsheet`) | Term note in `vault/resources/term_dictionary/`; do NOT add a new top-level BB type without a design discussion |
11
+ | New retrieval strategy | Module in `src/tessellum/retrieval/`; add a smoke test in `tests/retrieval/`; update `docs/architecture.md` |
12
+ | New documentation | `vault/` (Tessellum dogfoods itself — there is no separate `docs/`). Pick the right BB-typed location: `term_dictionary/` for definitions, `how_to/` for procedures, `analysis_thoughts/` for arguments + trails, `0_entry_points/` for navigation indexes. |
13
+ | Bug fix | Open an issue first describing the bug; reference it in the PR |
14
+ | Architecture proposal | Open an RFC issue; draft a Folgezettel trail in `vault/resources/analysis_thoughts/` if accepted |
15
+
16
+ ## Layout Convention
17
+
18
+ Every artifact has a single home. Don't mix.
19
+
20
+ | Artifact | Location |
21
+ |---|---|
22
+ | `import`-able Python | `src/tessellum/` |
23
+ | Knowledge vault content (your notes) | `vault/` |
24
+ | User input (PDFs, .eml, papers, plans) | `inbox/` |
25
+ | Generated DBs / indexes | `data/` (gitignored) |
26
+ | Experiment outputs | `experiments/` |
27
+ | Operational scripts | `scripts/` |
28
+ | Tests | `tests/` |
29
+ | Public documentation | `docs/` |
30
+ | Skill thin-header (Claude / Kiro) | `.claude/skills/`, `.kiro/skills/` |
31
+ | Skill canonical body (the actual content) | `vault/resources/skills/` |
32
+
33
+ See [`DEVELOPING.md`](DEVELOPING.md) for the full layout discussion.
34
+
35
+ ## Note Format Standards
36
+
37
+ Every typed atomic note ("tessellum") MUST have:
38
+
39
+ ```yaml
40
+ ---
41
+ tags:
42
+ - <category-tag> # First tag describes the note's role (resource, area, project, archive)
43
+ - <building-block-tag> # Second tag describes BB type (concept, procedure, model, argument, ...)
44
+ - <topic-tag> # Additional topic tags for retrieval
45
+ keywords:
46
+ - <key-term-1>
47
+ - <key-term-2>
48
+ topics:
49
+ - <topic-1>
50
+ language: markdown
51
+ date of note: YYYY-MM-DD
52
+ status: active
53
+ building_block: <concept|procedure|model|argument|counter_argument|hypothesis|empirical_observation|navigation>
54
+ ---
55
+ ```
56
+
57
+ Required H2 sections vary by BB type — see `docs/note-format.md`. The validator runs as a pre-commit hook:
58
+
59
+ ```bash
60
+ python scripts/check_yaml_frontmatter.py --path vault/<your-note>.md
61
+ python scripts/check_note_format.py --path vault/<your-note>.md
62
+ ```
63
+
64
+ ## Folgezettel Trail Etiquette
65
+
66
+ If your contribution introduces a new architectural argument, it deserves a Folgezettel trail. Pattern:
67
+
68
+ 1. Author the **root note** as an `argument` BB in `vault/resources/analysis_thoughts/thought_<your_topic>.md`
69
+ 2. Run `tessellum trail next <parent>` to get the next FZ ID (or claim a new root by using a number not yet taken)
70
+ 3. Write child notes that elaborate (`<root>a`, `<root>b`, ...), challenge (`<root>1` as `counter_argument`), or absorb into synthesis (`<counter>1` as `argument`)
71
+ 4. Update `vault/0_entry_points/entry_folgezettel_trails.md` with a row for the new trail
72
+
73
+ Trails should encode dialectic descent — argument → counter → response → reframe — not just topical proximity.
74
+
75
+ ## Skill Authoring
76
+
77
+ Skills live in three places (the in-vault SoT pattern):
78
+
79
+ 1. **Canonical body**: `vault/resources/skills/skill_<name>.md` — the actual procedure
80
+ 2. **Claude thin header**: `.claude/skills/<name>/SKILL.md` — points at the canonical body
81
+ 3. **Kiro thin header**: `.kiro/skills/<name>/SKILL.md` — same pattern
82
+ 4. **Pipeline sidecar** (if the skill has typed-contract steps): `vault/resources/skills/skill_<name>.pipeline.yaml`
83
+
84
+ The thin headers ensure both ecosystems (Claude Code, Kiro CLI) can discover the skill without duplicating the body. See an existing skill for reference.
85
+
86
+ ## Testing
87
+
88
+ Run the full test suite:
89
+
90
+ ```bash
91
+ pip install -e ".[dev]"
92
+ pytest
93
+ ```
94
+
95
+ Add tests under `tests/` mirroring the source structure (`tests/composer/`, `tests/retrieval/`, etc.). Smoke tests for end-to-end flows live in `tests/smoke/`.
96
+
97
+ ## Code Style
98
+
99
+ - Python 3.11+
100
+ - `ruff` for formatting and linting (config in `pyproject.toml`)
101
+ - `mypy` for type checking (gradual; not strict)
102
+ - Imperative commit messages: `add: skill_capture_essay_note` / `fix: rrf merge bug` / `docs: clarify BB ontology`
103
+
104
+ ## Pull Request Process
105
+
106
+ 1. Open an issue describing what you're proposing (unless it's a trivial bug fix)
107
+ 2. Branch from `main`: `git checkout -b feature/your-thing`
108
+ 3. Write tests
109
+ 4. Make sure `pytest` and `ruff check src/` both pass
110
+ 5. Open the PR with a clear description; reference the issue
111
+ 6. Maintainer review — typically within a week
112
+
113
+ ## Code of Conduct
114
+
115
+ Be kind, be precise, attack the argument not the person. Tessellum is a system that takes counter-arguments seriously; the project's culture should mirror that.
116
+
117
+ ## License
118
+
119
+ By contributing, you agree your contributions are licensed under the [MIT License](LICENSE).
@@ -0,0 +1,127 @@
1
+ # Developing Tessellum
2
+
3
+ Developer-facing guide for working on Tessellum itself (not for users of Tessellum). For user docs, browse `vault/0_entry_points/entry_master_toc.md`.
4
+
5
+ ## Layout Convention
6
+
7
+ Tessellum **dogfoods itself** — its public documentation lives in `vault/` as typed atomic notes following the same Building Block format the system asks of users. There is no separate `docs/` directory.
8
+
9
+ | Artifact | Location | Reason |
10
+ |---|---|---|
11
+ | `import`-able Python | `src/tessellum/` | PEP src-layout — installed package surface |
12
+ | Knowledge content (incl. Tessellum's own docs) | `vault/` | Single SoT for typed knowledge; self-applied retrieval |
13
+ | Skill canonical bodies | `vault/resources/skills/` | In-vault skill SoT pattern (FZ 12) |
14
+ | Skill thin-headers | `.claude/skills/`, `.kiro/skills/` | Per-ecosystem entry; both point at the canonical body |
15
+ | User input (PDFs, papers, plans) | `inbox/` | User-facing drop zone |
16
+ | Generated DBs / indexes | `data/` | Regenerable; gitignored |
17
+ | Experiment outputs | `experiments/` | Per-run subdirs |
18
+ | Operational scripts | `scripts/` | Build / update / format utilities |
19
+ | Tests | `tests/` | Mirrors `src/tessellum/` structure |
20
+ | Repo-meta files | repo root | `README.md`, `CHANGELOG.md`, `LICENSE`, `CONTRIBUTING.md`, `DEVELOPING.md`, `pyproject.toml`, `.gitignore`, `.github/` |
21
+
22
+ **Decision rule for new files**: if it would be useful to *anyone using Tessellum*, it goes in `vault/` as a typed atomic note. If it's only useful to *people working on Tessellum's code*, it goes at repo root or in `scripts/`.
23
+
24
+ ## Why dogfooding?
25
+
26
+ Three reasons:
27
+
28
+ 1. **Self-applied retrieval** — `tessellum search "BB ontology"` finds the public-facing explanation. Users can grep the system's own docs from day one.
29
+ 2. **Format conformance** — Tessellum's own documentation has to follow the format Tessellum demands of its users. If we can't make our docs fit, we're asking users to do something we won't do ourselves.
30
+ 3. **Demonstrates the system on itself** — a new user opens the repo, browses `vault/`, and sees a working example of the system documenting itself. That's the strongest README possible.
31
+
32
+ This decision is documented in [`vault/resources/analysis_thoughts/thought_dogfooding_decision.md`](vault/resources/analysis_thoughts/thought_dogfooding_decision.md) (planned for v0.1).
33
+
34
+ ## Path Resolution
35
+
36
+ All paths flow through `scripts/config.py` (single SoT). The constants:
37
+
38
+ ```python
39
+ REPO_ROOT = Path(__file__).resolve().parent.parent
40
+ PACKAGE_DIR = REPO_ROOT / "src" / "tessellum"
41
+ VAULT_PATH = REPO_ROOT / "vault"
42
+ INBOX_PATH = REPO_ROOT / "inbox"
43
+ DATA_PATH = REPO_ROOT / "data"
44
+ DB_PATH = DATA_PATH / "databases" / "tessellum_unified.db"
45
+ EXPERIMENTS_PATH = REPO_ROOT / "experiments"
46
+ ```
47
+
48
+ Skills and scripts MUST import from `config.py`. Never hardcode a path.
49
+
50
+ ## Dev Setup
51
+
52
+ ```bash
53
+ # Clone
54
+ git clone https://github.com/TianpeiLuke/Tessellum.git
55
+ cd Tessellum
56
+
57
+ # Install in editable mode with dev extras
58
+ pip install -e ".[dev]"
59
+
60
+ # Run the test suite
61
+ pytest
62
+
63
+ # Lint + format
64
+ ruff check src/
65
+ ruff format src/
66
+
67
+ # Type check (gradual; not strict)
68
+ mypy src/tessellum/
69
+ ```
70
+
71
+ ## Adding a Skill
72
+
73
+ Skills live in **three** files (the in-vault SoT pattern):
74
+
75
+ 1. **Canonical body**: `vault/resources/skills/skill_<name>.md` — the actual procedure (YAML frontmatter + steps + format spec)
76
+ 2. **Claude thin-header**: `.claude/skills/<name>/SKILL.md` — short pointer to the canonical body
77
+ 3. **Kiro thin-header**: `.kiro/skills/<name>/SKILL.md` — same pattern
78
+ 4. **Pipeline sidecar** (optional): `vault/resources/skills/skill_<name>.pipeline.yaml` — only if the skill has typed-contract steps
79
+
80
+ ## Adding a Building Block sub-kind
81
+
82
+ The 8 top-level BB types are **closed**. Sub-kinds (`note_second_category:`) are **open** — extend as your domain requires. Procedure:
83
+
84
+ 1. Add the sub-kind value to your note's YAML frontmatter
85
+ 2. Add a term note in `vault/resources/term_dictionary/term_<subkind>.md` documenting it
86
+ 3. Run `bash scripts/update_notes_database.sh` to re-index
87
+
88
+ If a sub-kind is generally useful (not domain-specific), open a PR adding it to `src/tessellum/format/building_blocks.py`'s sub-kind suggestion list (planned in v0.1).
89
+
90
+ ## Adding a Folgezettel trail
91
+
92
+ If your contribution introduces a new architectural argument, it deserves a Folgezettel trail. Pattern:
93
+
94
+ 1. Author the **root note** as an `argument` BB at `vault/resources/analysis_thoughts/thought_<topic>.md`; set `folgezettel: "<N>"` (next root number) and `fz_parent: null`
95
+ 2. Write child notes that elaborate, challenge, or absorb into synthesis
96
+ 3. Update `vault/0_entry_points/entry_folgezettel_trails.md` with the new trail's row + ASCII tree
97
+
98
+ See [`vault/resources/term_dictionary/term_folgezettel.md`](vault/resources/term_dictionary/term_folgezettel.md) (planned v0.1) for the full convention.
99
+
100
+ ## Release Process
101
+
102
+ 1. Update `CHANGELOG.md` with the release notes
103
+ 2. Bump `version` in `pyproject.toml`
104
+ 3. Tag the release: `git tag v0.x.y && git push --tags`
105
+ 4. Build: `python -m build`
106
+ 5. Upload: `twine upload dist/*`
107
+ 6. The `.github/workflows/publish.yml` workflow runs the upload automatically on tag push (planned v0.1)
108
+
109
+ ## Code Style
110
+
111
+ - **Python 3.11+**
112
+ - **Ruff** for formatting and linting (config in `pyproject.toml`)
113
+ - **Mypy** for type checking — gradual, not strict
114
+ - **Imperative commit messages**: `add: skill_capture_essay_note` / `fix: rrf merge bug` / `docs(vault): clarify BB ontology`
115
+
116
+ ## CI
117
+
118
+ The CI workflow (`.github/workflows/ci.yml`, planned v0.1) runs:
119
+ - `ruff check src/`
120
+ - `ruff format --check src/`
121
+ - `pytest`
122
+ - `python scripts/check_yaml_frontmatter.py --path vault/`
123
+ - `python scripts/check_note_format.py --path vault/`
124
+
125
+ ## License
126
+
127
+ [MIT](LICENSE).
@@ -0,0 +1,21 @@
1
+ MIT License
2
+
3
+ Copyright (c) 2026 Tianpei Xie
4
+
5
+ Permission is hereby granted, free of charge, to any person obtaining a copy
6
+ of this software and associated documentation files (the "Software"), to deal
7
+ in the Software without restriction, including without limitation the rights
8
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9
+ copies of the Software, and to permit persons to whom the Software is
10
+ furnished to do so, subject to the following conditions:
11
+
12
+ The above copyright notice and this permission notice shall be included in all
13
+ copies or substantial portions of the Software.
14
+
15
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21
+ SOFTWARE.