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.
- tessellum-0.0.1/.gitignore +218 -0
- tessellum-0.0.1/CHANGELOG.md +36 -0
- tessellum-0.0.1/CONTRIBUTING.md +119 -0
- tessellum-0.0.1/DEVELOPING.md +127 -0
- tessellum-0.0.1/LICENSE +21 -0
- tessellum-0.0.1/PKG-INFO +217 -0
- tessellum-0.0.1/README.md +143 -0
- tessellum-0.0.1/pyproject.toml +162 -0
- tessellum-0.0.1/src/tessellum/__init__.py +29 -0
- tessellum-0.0.1/src/tessellum/format/__init__.py +30 -0
- tessellum-0.0.1/src/tessellum/format/building_blocks.py +339 -0
- tessellum-0.0.1/vault/0_entry_points/entry_master_toc.md +110 -0
- tessellum-0.0.1/vault/resources/term_dictionary/term_building_block.md +155 -0
- tessellum-0.0.1/vault/resources/term_dictionary/term_cqrs.md +101 -0
- tessellum-0.0.1/vault/resources/term_dictionary/term_dialectic_knowledge_system.md +163 -0
- tessellum-0.0.1/vault/resources/term_dictionary/term_epistemic_function.md +154 -0
- tessellum-0.0.1/vault/resources/term_dictionary/term_folgezettel.md +143 -0
- tessellum-0.0.1/vault/resources/term_dictionary/term_para_method.md +145 -0
- tessellum-0.0.1/vault/resources/term_dictionary/term_slipbox.md +120 -0
- tessellum-0.0.1/vault/resources/term_dictionary/term_zettelkasten.md +334 -0
|
@@ -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).
|
tessellum-0.0.1/LICENSE
ADDED
|
@@ -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.
|