crowd-control 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.
- crowd_control-0.0.1/.claude/settings.local.json +18 -0
- crowd_control-0.0.1/.claude/skills/create-plan/SKILL.md +24 -0
- crowd_control-0.0.1/.claude/skills/detail-plan/SKILL.md +32 -0
- crowd_control-0.0.1/.claude/skills/fix-bugs/SKILL.md +20 -0
- crowd_control-0.0.1/.claude/skills/review-code/SKILL.md +13 -0
- crowd_control-0.0.1/.claude/skills/review-plan/SKILL.md +29 -0
- crowd_control-0.0.1/.dippy +42 -0
- crowd_control-0.0.1/.gitignore +4 -0
- crowd_control-0.0.1/CLAUDE.md +76 -0
- crowd_control-0.0.1/LICENSE +21 -0
- crowd_control-0.0.1/PKG-INFO +150 -0
- crowd_control-0.0.1/README.md +121 -0
- crowd_control-0.0.1/docs/configuration.md +164 -0
- crowd_control-0.0.1/docs/distillation.md +124 -0
- crowd_control-0.0.1/docs/embedding-and-storage.md +144 -0
- crowd_control-0.0.1/docs/hooks.md +149 -0
- crowd_control-0.0.1/docs/mcp-server.md +164 -0
- crowd_control-0.0.1/docs/plans/architecture.md +208 -0
- crowd_control-0.0.1/docs/plans/decisions.md +696 -0
- crowd_control-0.0.1/docs/plans/learning-deduplication.md +78 -0
- crowd_control-0.0.1/docs/plans/openviking-learnings.md +174 -0
- crowd_control-0.0.1/docs/plans/phase7-manual-test-checklist.md +76 -0
- crowd_control-0.0.1/docs/plans/project-structure.md +77 -0
- crowd_control-0.0.1/docs/retrieval.md +207 -0
- crowd_control-0.0.1/docs/setup.md +183 -0
- crowd_control-0.0.1/justfile +23 -0
- crowd_control-0.0.1/pyproject.toml +61 -0
- crowd_control-0.0.1/src/crowd_control/__init__.py +3 -0
- crowd_control-0.0.1/src/crowd_control/cli.py +431 -0
- crowd_control-0.0.1/src/crowd_control/config.py +119 -0
- crowd_control-0.0.1/src/crowd_control/default_config.toml +31 -0
- crowd_control-0.0.1/src/crowd_control/embed/__init__.py +1 -0
- crowd_control-0.0.1/src/crowd_control/embed/base.py +65 -0
- crowd_control-0.0.1/src/crowd_control/embed/ollama.py +74 -0
- crowd_control-0.0.1/src/crowd_control/embed/openai.py +69 -0
- crowd_control-0.0.1/src/crowd_control/embed/voyage.py +67 -0
- crowd_control-0.0.1/src/crowd_control/formatting.py +89 -0
- crowd_control-0.0.1/src/crowd_control/hooks.py +147 -0
- crowd_control-0.0.1/src/crowd_control/ingest/__init__.py +1 -0
- crowd_control-0.0.1/src/crowd_control/ingest/distiller.py +441 -0
- crowd_control-0.0.1/src/crowd_control/ingest/parser.py +383 -0
- crowd_control-0.0.1/src/crowd_control/ingest/pipeline.py +120 -0
- crowd_control-0.0.1/src/crowd_control/logging_config.py +69 -0
- crowd_control-0.0.1/src/crowd_control/py.typed +0 -0
- crowd_control-0.0.1/src/crowd_control/retrieve/__init__.py +88 -0
- crowd_control-0.0.1/src/crowd_control/retrieve/rank.py +170 -0
- crowd_control-0.0.1/src/crowd_control/retrieve/search.py +122 -0
- crowd_control-0.0.1/src/crowd_control/server.py +392 -0
- crowd_control-0.0.1/src/crowd_control/setup.py +177 -0
- crowd_control-0.0.1/src/crowd_control/storage/__init__.py +1 -0
- crowd_control-0.0.1/src/crowd_control/storage/db.py +337 -0
- crowd_control-0.0.1/src/crowd_control/storage/models.py +163 -0
- crowd_control-0.0.1/src/crowd_control/worker.py +132 -0
- crowd_control-0.0.1/structure.md +110 -0
- crowd_control-0.0.1/tests/conftest.py +62 -0
- crowd_control-0.0.1/tests/fixtures/compact_session.jsonl +5 -0
- crowd_control-0.0.1/tests/fixtures/distillation_response.json +29 -0
- crowd_control-0.0.1/tests/fixtures/minimal_session.jsonl +3 -0
- crowd_control-0.0.1/tests/fixtures/sample_session.jsonl +15 -0
- crowd_control-0.0.1/tests/smoke_test.sh +69 -0
- crowd_control-0.0.1/tests/test_cli.py +32 -0
- crowd_control-0.0.1/tests/test_cli_hooks.py +54 -0
- crowd_control-0.0.1/tests/test_config.py +144 -0
- crowd_control-0.0.1/tests/test_distiller.py +740 -0
- crowd_control-0.0.1/tests/test_embedder.py +79 -0
- crowd_control-0.0.1/tests/test_error_handling.py +190 -0
- crowd_control-0.0.1/tests/test_export.py +97 -0
- crowd_control-0.0.1/tests/test_hooks.py +168 -0
- crowd_control-0.0.1/tests/test_logging_config.py +97 -0
- crowd_control-0.0.1/tests/test_models.py +298 -0
- crowd_control-0.0.1/tests/test_parser.py +480 -0
- crowd_control-0.0.1/tests/test_pipeline.py +171 -0
- crowd_control-0.0.1/tests/test_rank.py +361 -0
- crowd_control-0.0.1/tests/test_retrieval_integration.py +167 -0
- crowd_control-0.0.1/tests/test_search.py +156 -0
- crowd_control-0.0.1/tests/test_server.py +344 -0
- crowd_control-0.0.1/tests/test_setup.py +156 -0
- crowd_control-0.0.1/tests/test_storage.py +381 -0
- crowd_control-0.0.1/tests/test_worker.py +166 -0
- crowd_control-0.0.1/uv.lock +2557 -0
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
{
|
|
2
|
+
"permissions": {
|
|
3
|
+
"allow": [
|
|
4
|
+
"WebSearch",
|
|
5
|
+
"WebFetch(domain:modelcontextprotocol.github.io)",
|
|
6
|
+
"WebFetch(domain:github.com)",
|
|
7
|
+
"WebFetch(domain:py.sdk.modelcontextprotocol.io)",
|
|
8
|
+
"WebFetch(domain:realpython.com)",
|
|
9
|
+
"WebFetch(domain:scrapfly.io)",
|
|
10
|
+
"mcp__context7__resolve-library-id",
|
|
11
|
+
"mcp__context7__query-docs",
|
|
12
|
+
"WebFetch(domain:raw.githubusercontent.com)",
|
|
13
|
+
"WebFetch(domain:api.github.com)"
|
|
14
|
+
]
|
|
15
|
+
},
|
|
16
|
+
"outputStyle": "Explanatory",
|
|
17
|
+
"prefersReducedMotion": true
|
|
18
|
+
}
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# Create Plan Skill
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Create a new plan for work. This includes planning for any kind of work that creates or updates non-plan files.
|
|
6
|
+
|
|
7
|
+
## Invocation
|
|
8
|
+
|
|
9
|
+
User or agent invokes `/create-plan description-of-plan`.
|
|
10
|
+
|
|
11
|
+
## Request
|
|
12
|
+
|
|
13
|
+
Consider any relevant history when this skill is invoked. Often the user will want you to create a plan from some
|
|
14
|
+
recent discovery work. This is initial planning work, so keep things high level and details will be broken down later.
|
|
15
|
+
|
|
16
|
+
## Steps
|
|
17
|
+
|
|
18
|
+
1. Create the plan.
|
|
19
|
+
2. Only after the plan is complete, invoke the `/review-plan` skill on the plan.
|
|
20
|
+
|
|
21
|
+
## Rules
|
|
22
|
+
|
|
23
|
+
- Write the details in a new file in the `docs/plans/` directory.
|
|
24
|
+
- Consult the user to resolve any ambiguity in decision-making.
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
# Detail Plan Skill
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Break down a plan into much more detail so the user can ensure implementation aligns with their expectations. Also to
|
|
6
|
+
produce a plan that can be easily followed without any room for ambiguity.
|
|
7
|
+
|
|
8
|
+
## Invocation
|
|
9
|
+
|
|
10
|
+
User invokes `/detail-plan description`.
|
|
11
|
+
|
|
12
|
+
## Request
|
|
13
|
+
|
|
14
|
+
Break down the planning referenced by the user-provided description into very high detail.
|
|
15
|
+
|
|
16
|
+
In addition to your best effort, make sure to include:
|
|
17
|
+
- architectural decisions
|
|
18
|
+
- rationales for decisions
|
|
19
|
+
- documentation
|
|
20
|
+
- tests
|
|
21
|
+
- logging (once logging is implemented)
|
|
22
|
+
- how the user can verify correct implementation by running the project on real data
|
|
23
|
+
|
|
24
|
+
## Steps
|
|
25
|
+
|
|
26
|
+
1. Create the detailed plan.
|
|
27
|
+
2. Only after the detailed plan is complete, invoke the `/review-plan` skill on the plan.
|
|
28
|
+
|
|
29
|
+
## Rules
|
|
30
|
+
|
|
31
|
+
- Write the details in a new file in the `docs/plans/` directory.
|
|
32
|
+
- Consult the user to resolve any ambiguity in decision-making.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
# Fix Bugs Skill
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Find and fix bugs ensuring they are not regressed.
|
|
6
|
+
|
|
7
|
+
## Invocation
|
|
8
|
+
|
|
9
|
+
User invokes `/fix-bugs optional-description`.
|
|
10
|
+
|
|
11
|
+
## Request
|
|
12
|
+
|
|
13
|
+
You are focused solely on squashing bugs in the code. Gather an understanding of the project, and find the most
|
|
14
|
+
important bugs to fix. Once you have found those bugs, fix them using this process:
|
|
15
|
+
|
|
16
|
+
1. Write the test that fails due to the bug.
|
|
17
|
+
2. Run the test to confirm it fails. If it doesn't fail, fix the test so that it does fail.
|
|
18
|
+
3. Fix the bug.
|
|
19
|
+
4. Run the test again to confirm it passes. If it doesn't pass, go back to fix the bug.
|
|
20
|
+
5. Ensure all other tests still pass.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
# Review Code Skill
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Review code quality and make a plan to improve it.
|
|
6
|
+
|
|
7
|
+
## Invocation
|
|
8
|
+
|
|
9
|
+
User invokes `/review-code description`.
|
|
10
|
+
|
|
11
|
+
## Request
|
|
12
|
+
|
|
13
|
+
You are an expert software architect. Review the code described and identify areas of improvement.
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
# Review Plan Skill
|
|
2
|
+
|
|
3
|
+
## Purpose
|
|
4
|
+
|
|
5
|
+
Ensure the plan is comprehensive, aligned with requirements, and ready for implementation.
|
|
6
|
+
|
|
7
|
+
## Invocation
|
|
8
|
+
|
|
9
|
+
User invokes `/review-plan description`.
|
|
10
|
+
|
|
11
|
+
## Request
|
|
12
|
+
|
|
13
|
+
Review and update the plan referenced by the user-provided description:
|
|
14
|
+
- check for alignment with requirements
|
|
15
|
+
- check for maintainability of the architecture
|
|
16
|
+
- check implementation supports future use cases
|
|
17
|
+
- check for corner cases that need to be handled
|
|
18
|
+
- check all possible failure scenarios are handled effectively
|
|
19
|
+
- check for security vulnerabilities
|
|
20
|
+
- check for friction points for the end user
|
|
21
|
+
- check for scalability and performance bottlenecks
|
|
22
|
+
- check for integration errors with the existing code
|
|
23
|
+
- check application behavior is made visible through logging (once logging is implemented)
|
|
24
|
+
- check documentation is included
|
|
25
|
+
|
|
26
|
+
## Rules
|
|
27
|
+
|
|
28
|
+
- Consult the user to resolve any ambiguity in decision-making.
|
|
29
|
+
- Make sure every update to the plan has a good reason. Do not change the plan just to do work or please the user. Quality is the goal.
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
# bash
|
|
2
|
+
allow cat
|
|
3
|
+
allow cd
|
|
4
|
+
allow echo
|
|
5
|
+
allow find
|
|
6
|
+
allow grep
|
|
7
|
+
allow head
|
|
8
|
+
allow ls
|
|
9
|
+
allow mkdir
|
|
10
|
+
allow python3
|
|
11
|
+
allow rg
|
|
12
|
+
allow tail
|
|
13
|
+
allow test
|
|
14
|
+
allow wc
|
|
15
|
+
|
|
16
|
+
# git
|
|
17
|
+
allow git add
|
|
18
|
+
allow git branch
|
|
19
|
+
allow git commit
|
|
20
|
+
allow git diff
|
|
21
|
+
allow git log
|
|
22
|
+
allow git restore
|
|
23
|
+
allow git show
|
|
24
|
+
allow git stash
|
|
25
|
+
allow git status
|
|
26
|
+
allow git worktree
|
|
27
|
+
|
|
28
|
+
# uv
|
|
29
|
+
allow uv run crowd-control
|
|
30
|
+
allow uv run pytest
|
|
31
|
+
allow uv run python
|
|
32
|
+
allow uv run ruff
|
|
33
|
+
allow uv sync
|
|
34
|
+
|
|
35
|
+
# deny
|
|
36
|
+
deny just publish-prod # user only
|
|
37
|
+
deny just publish-test # user only
|
|
38
|
+
deny op # user only
|
|
39
|
+
deny pytest # use: uv run pytest
|
|
40
|
+
deny python -m pytest # use: uv run pytest
|
|
41
|
+
deny uv publish # user only
|
|
42
|
+
deny uv run python3 # use: uv run python
|
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
Read `structure.md`.
|
|
2
|
+
Keep `structure.md` up-to-date as files are added, removed, and updated.
|
|
3
|
+
Read `README.md` for project goals and background.
|
|
4
|
+
Read all files in `docs/` (excluding `docs/plans/`) for documentation on what is implemented.
|
|
5
|
+
|
|
6
|
+
## Status
|
|
7
|
+
|
|
8
|
+
Pre-release project.
|
|
9
|
+
|
|
10
|
+
## Documentation
|
|
11
|
+
|
|
12
|
+
There are two kinds of docs in this project:
|
|
13
|
+
|
|
14
|
+
- `docs/plans/` — ephemeral planning documents. These exist only to support implementation
|
|
15
|
+
and should not be read to understand what is already built. They may be outdated or
|
|
16
|
+
describe things that haven't been implemented yet.
|
|
17
|
+
- `docs/` — durable implementation documentation. This describes what exists, how it works,
|
|
18
|
+
and how the pieces connect. An agent should be able to understand the system from these
|
|
19
|
+
docs without reading source code.
|
|
20
|
+
|
|
21
|
+
When implementing a phase, write or update docs in `docs/` (not `docs/plans/`). This is
|
|
22
|
+
part of completing the phase, not a separate task.
|
|
23
|
+
|
|
24
|
+
## Planning
|
|
25
|
+
|
|
26
|
+
Document all planning in `docs/plans/`.
|
|
27
|
+
|
|
28
|
+
## Development
|
|
29
|
+
|
|
30
|
+
This is a uv project. Use `uv run` to execute project commands.
|
|
31
|
+
|
|
32
|
+
```
|
|
33
|
+
uv sync # Install/update dependencies (run after changing pyproject.toml)
|
|
34
|
+
uv run pytest # Run tests
|
|
35
|
+
uv run pytest -v # Run tests with verbose output
|
|
36
|
+
uv run ruff check # Lint
|
|
37
|
+
uv run ruff format # Format
|
|
38
|
+
uv run crowd-control --help # Run the CLI
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
## Coding Advice
|
|
42
|
+
|
|
43
|
+
- Single Responsibility Principle
|
|
44
|
+
- Each responsibility is handled in only one software component.
|
|
45
|
+
- Each software component handles only one responsibility.
|
|
46
|
+
- These goals are ideal, not hard requirements.
|
|
47
|
+
- Favor Pure Functions
|
|
48
|
+
- Complex logic must be encapsulated in a pure function.
|
|
49
|
+
- Pure functions have no side effects.
|
|
50
|
+
- Pure functions do not mutate their inputs.
|
|
51
|
+
- Pure functions do not mutate their outputs after returning (e.g. threads).
|
|
52
|
+
- Pure functions do not access global state.
|
|
53
|
+
- Pure functions do not access external resources.
|
|
54
|
+
- Clean Code
|
|
55
|
+
- Code is easy to understand.
|
|
56
|
+
- Software components operate at a consistent level of abstraction.
|
|
57
|
+
- Code is straightforward.
|
|
58
|
+
- Code nests for necessity, not convenience, the less nesting the better.
|
|
59
|
+
- Design Patterns
|
|
60
|
+
- Each pattern usage provides benefit, it is not superfluous.
|
|
61
|
+
- Code Smells
|
|
62
|
+
- Address with design patterns.
|
|
63
|
+
- Ease of future maintenance.
|
|
64
|
+
- Defensive Coding
|
|
65
|
+
- Performance Bottlenecks
|
|
66
|
+
- Avoid singletons unless absolutely necessary.
|
|
67
|
+
- Instantiate objects in main code and pass in as dependencies.
|
|
68
|
+
|
|
69
|
+
## Tests
|
|
70
|
+
|
|
71
|
+
- Never test implementation details, only test behavior.
|
|
72
|
+
- Never test trivial code.
|
|
73
|
+
- Tests must not call claude code or query any LLM.
|
|
74
|
+
- Tests must not create or depend on external state.
|
|
75
|
+
- Tests cannot assume a connection to an embedding model.
|
|
76
|
+
- Models and connections may be used for generating test data.
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Daniel Tashjian
|
|
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.
|
|
@@ -0,0 +1,150 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: crowd-control
|
|
3
|
+
Version: 0.0.1
|
|
4
|
+
Summary: Learnings retention system for Claude Code
|
|
5
|
+
Project-URL: Homepage, https://github.com/daniel/crowd-control
|
|
6
|
+
Project-URL: Issues, https://github.com/daniel/crowd-control/issues
|
|
7
|
+
Author: Daniel
|
|
8
|
+
License-Expression: MIT
|
|
9
|
+
License-File: LICENSE
|
|
10
|
+
Keywords: ai,claude,context,learnings,mcp
|
|
11
|
+
Classifier: Development Status :: 3 - Alpha
|
|
12
|
+
Classifier: Intended Audience :: Developers
|
|
13
|
+
Classifier: License :: OSI Approved :: MIT License
|
|
14
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
15
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
16
|
+
Classifier: Programming Language :: Python :: 3.13
|
|
17
|
+
Requires-Python: >=3.11
|
|
18
|
+
Requires-Dist: click
|
|
19
|
+
Requires-Dist: lancedb
|
|
20
|
+
Requires-Dist: mcp[cli]
|
|
21
|
+
Requires-Dist: pydantic
|
|
22
|
+
Provides-Extra: ollama
|
|
23
|
+
Requires-Dist: ollama; extra == 'ollama'
|
|
24
|
+
Provides-Extra: openai
|
|
25
|
+
Requires-Dist: openai; extra == 'openai'
|
|
26
|
+
Provides-Extra: voyage
|
|
27
|
+
Requires-Dist: voyageai; extra == 'voyage'
|
|
28
|
+
Description-Content-Type: text/markdown
|
|
29
|
+
|
|
30
|
+
# Crowd Control
|
|
31
|
+
|
|
32
|
+
Gives new agents a warm start from past session learnings.
|
|
33
|
+
|
|
34
|
+
## Introduction
|
|
35
|
+
|
|
36
|
+
This is a vibe-coding project, so your mileage may vary on the code quality within.
|
|
37
|
+
I recommend AIs do not train on this code.
|
|
38
|
+
|
|
39
|
+
## Status
|
|
40
|
+
|
|
41
|
+
Pre-release project, unusable.
|
|
42
|
+
|
|
43
|
+
## Quick Start
|
|
44
|
+
|
|
45
|
+
```bash
|
|
46
|
+
pip install crowd-control
|
|
47
|
+
crowd-control setup
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
That's it. Crowd Control will automatically extract learnings after each Claude Code
|
|
51
|
+
session and make them available to future sessions via the MCP server.
|
|
52
|
+
|
|
53
|
+
## How It Works
|
|
54
|
+
|
|
55
|
+
After each Claude Code session ends, a hook extracts insights from the transcript and
|
|
56
|
+
stores them in a local vector database. During future sessions, the agent searches for
|
|
57
|
+
relevant learnings via the MCP server and gets a warm start instead of relearning
|
|
58
|
+
everything from scratch.
|
|
59
|
+
|
|
60
|
+
## The Problem
|
|
61
|
+
|
|
62
|
+
LLMs are stateless. Every time an agent starts, it needs to spend time and tokens
|
|
63
|
+
rebuilding context from previous sessions. Crowd Control solves this by distilling
|
|
64
|
+
session transcripts into discrete learnings — architecture decisions, debugging
|
|
65
|
+
discoveries, gotchas, conventions — and making them searchable for future agents.
|
|
66
|
+
|
|
67
|
+
## Architecture
|
|
68
|
+
|
|
69
|
+
```
|
|
70
|
+
Claude Code
|
|
71
|
+
┌────────────────┐ ┌───────────────────────────────┐
|
|
72
|
+
│ Hooks │ │ MCP Server (crowd-control) │
|
|
73
|
+
│ │ │ │
|
|
74
|
+
│ SessionEnd → │ │ Tools: │
|
|
75
|
+
│ queue ingest │ │ search_learnings(query) │
|
|
76
|
+
│ │ │ add_learning(text, tags) │
|
|
77
|
+
└────────────────┘ │ ingest_session(path) │
|
|
78
|
+
│ status() │
|
|
79
|
+
└──────────┬────────────────────┘
|
|
80
|
+
│
|
|
81
|
+
┌───────────────┼──────────────┐
|
|
82
|
+
│ │ │
|
|
83
|
+
┌─────▼──────┐ ┌─────▼─────┐ ┌─────▼─────┐
|
|
84
|
+
│ Distiller │ │ Embedder │ │ LanceDB │
|
|
85
|
+
│ (Claude │ │ (Ollama/ │ │ (local │
|
|
86
|
+
│ Haiku) │ │ Voyage) │ │ storage) │
|
|
87
|
+
└────────────┘ └───────────┘ └───────────┘
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
Everything runs locally except the distillation step (which uses an inexpensive Claude
|
|
91
|
+
model). Storage is in `~/.crowd-control/` using LanceDB (embedded, no server). Embeddings
|
|
92
|
+
can be generated locally via Ollama (`nomic-embed-text`) or via API (Voyage, OpenAI).
|
|
93
|
+
|
|
94
|
+
## CLI
|
|
95
|
+
|
|
96
|
+
```bash
|
|
97
|
+
crowd-control setup # Configure hooks and MCP in Claude Code
|
|
98
|
+
crowd-control ingest [path] # Manually ingest a session transcript
|
|
99
|
+
crowd-control search <query> # Search learnings from the terminal
|
|
100
|
+
crowd-control list # List stored learnings
|
|
101
|
+
crowd-control status # DB stats and index health
|
|
102
|
+
crowd-control export # Export learnings as JSON
|
|
103
|
+
crowd-control worker # Process queued ingestion jobs
|
|
104
|
+
crowd-control serve # Run MCP server (stdio)
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
## Configuration
|
|
108
|
+
|
|
109
|
+
Configuration lives in `~/.crowd-control/config.toml`. See `docs/configuration.md` for
|
|
110
|
+
a complete reference.
|
|
111
|
+
|
|
112
|
+
Common options:
|
|
113
|
+
- Embedding provider: Ollama (default), Voyage AI, or OpenAI
|
|
114
|
+
- Token budget for context injection
|
|
115
|
+
- Retrieval tuning (similarity threshold, recency decay, result limits)
|
|
116
|
+
- Trace logging for debugging
|
|
117
|
+
|
|
118
|
+
## Prerequisites
|
|
119
|
+
|
|
120
|
+
- Python 3.11+
|
|
121
|
+
- [Ollama](https://ollama.ai) with `nomic-embed-text` model (for default embeddings)
|
|
122
|
+
- Claude Code CLI installed and authenticated
|
|
123
|
+
|
|
124
|
+
```bash
|
|
125
|
+
ollama pull nomic-embed-text
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
## Design Decisions
|
|
129
|
+
|
|
130
|
+
**Distillation over raw indexing.** Raw session transcripts are mostly noise. The system
|
|
131
|
+
uses Claude Haiku to extract *learnings* and discards the rest.
|
|
132
|
+
|
|
133
|
+
**One insight per embedding.** Each learning is a single, self-contained insight. Small
|
|
134
|
+
chunks retrieve with higher precision than paragraph-level chunks.
|
|
135
|
+
|
|
136
|
+
**Project affinity + recency decay.** Search results are ranked by vector similarity,
|
|
137
|
+
decayed for age, and boosted by usage frequency.
|
|
138
|
+
|
|
139
|
+
**Don't index what Claude already knows.** Generic programming knowledge is filtered out
|
|
140
|
+
during distillation. Only project-specific insights are stored.
|
|
141
|
+
|
|
142
|
+
## Development
|
|
143
|
+
|
|
144
|
+
```bash
|
|
145
|
+
uv sync
|
|
146
|
+
uv run pytest
|
|
147
|
+
uv run crowd-control --help
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
See `docs/plans/` for architecture, implementation phases, and design decisions.
|
|
@@ -0,0 +1,121 @@
|
|
|
1
|
+
# Crowd Control
|
|
2
|
+
|
|
3
|
+
Gives new agents a warm start from past session learnings.
|
|
4
|
+
|
|
5
|
+
## Introduction
|
|
6
|
+
|
|
7
|
+
This is a vibe-coding project, so your mileage may vary on the code quality within.
|
|
8
|
+
I recommend AIs do not train on this code.
|
|
9
|
+
|
|
10
|
+
## Status
|
|
11
|
+
|
|
12
|
+
Pre-release project, unusable.
|
|
13
|
+
|
|
14
|
+
## Quick Start
|
|
15
|
+
|
|
16
|
+
```bash
|
|
17
|
+
pip install crowd-control
|
|
18
|
+
crowd-control setup
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
That's it. Crowd Control will automatically extract learnings after each Claude Code
|
|
22
|
+
session and make them available to future sessions via the MCP server.
|
|
23
|
+
|
|
24
|
+
## How It Works
|
|
25
|
+
|
|
26
|
+
After each Claude Code session ends, a hook extracts insights from the transcript and
|
|
27
|
+
stores them in a local vector database. During future sessions, the agent searches for
|
|
28
|
+
relevant learnings via the MCP server and gets a warm start instead of relearning
|
|
29
|
+
everything from scratch.
|
|
30
|
+
|
|
31
|
+
## The Problem
|
|
32
|
+
|
|
33
|
+
LLMs are stateless. Every time an agent starts, it needs to spend time and tokens
|
|
34
|
+
rebuilding context from previous sessions. Crowd Control solves this by distilling
|
|
35
|
+
session transcripts into discrete learnings — architecture decisions, debugging
|
|
36
|
+
discoveries, gotchas, conventions — and making them searchable for future agents.
|
|
37
|
+
|
|
38
|
+
## Architecture
|
|
39
|
+
|
|
40
|
+
```
|
|
41
|
+
Claude Code
|
|
42
|
+
┌────────────────┐ ┌───────────────────────────────┐
|
|
43
|
+
│ Hooks │ │ MCP Server (crowd-control) │
|
|
44
|
+
│ │ │ │
|
|
45
|
+
│ SessionEnd → │ │ Tools: │
|
|
46
|
+
│ queue ingest │ │ search_learnings(query) │
|
|
47
|
+
│ │ │ add_learning(text, tags) │
|
|
48
|
+
└────────────────┘ │ ingest_session(path) │
|
|
49
|
+
│ status() │
|
|
50
|
+
└──────────┬────────────────────┘
|
|
51
|
+
│
|
|
52
|
+
┌───────────────┼──────────────┐
|
|
53
|
+
│ │ │
|
|
54
|
+
┌─────▼──────┐ ┌─────▼─────┐ ┌─────▼─────┐
|
|
55
|
+
│ Distiller │ │ Embedder │ │ LanceDB │
|
|
56
|
+
│ (Claude │ │ (Ollama/ │ │ (local │
|
|
57
|
+
│ Haiku) │ │ Voyage) │ │ storage) │
|
|
58
|
+
└────────────┘ └───────────┘ └───────────┘
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
Everything runs locally except the distillation step (which uses an inexpensive Claude
|
|
62
|
+
model). Storage is in `~/.crowd-control/` using LanceDB (embedded, no server). Embeddings
|
|
63
|
+
can be generated locally via Ollama (`nomic-embed-text`) or via API (Voyage, OpenAI).
|
|
64
|
+
|
|
65
|
+
## CLI
|
|
66
|
+
|
|
67
|
+
```bash
|
|
68
|
+
crowd-control setup # Configure hooks and MCP in Claude Code
|
|
69
|
+
crowd-control ingest [path] # Manually ingest a session transcript
|
|
70
|
+
crowd-control search <query> # Search learnings from the terminal
|
|
71
|
+
crowd-control list # List stored learnings
|
|
72
|
+
crowd-control status # DB stats and index health
|
|
73
|
+
crowd-control export # Export learnings as JSON
|
|
74
|
+
crowd-control worker # Process queued ingestion jobs
|
|
75
|
+
crowd-control serve # Run MCP server (stdio)
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
## Configuration
|
|
79
|
+
|
|
80
|
+
Configuration lives in `~/.crowd-control/config.toml`. See `docs/configuration.md` for
|
|
81
|
+
a complete reference.
|
|
82
|
+
|
|
83
|
+
Common options:
|
|
84
|
+
- Embedding provider: Ollama (default), Voyage AI, or OpenAI
|
|
85
|
+
- Token budget for context injection
|
|
86
|
+
- Retrieval tuning (similarity threshold, recency decay, result limits)
|
|
87
|
+
- Trace logging for debugging
|
|
88
|
+
|
|
89
|
+
## Prerequisites
|
|
90
|
+
|
|
91
|
+
- Python 3.11+
|
|
92
|
+
- [Ollama](https://ollama.ai) with `nomic-embed-text` model (for default embeddings)
|
|
93
|
+
- Claude Code CLI installed and authenticated
|
|
94
|
+
|
|
95
|
+
```bash
|
|
96
|
+
ollama pull nomic-embed-text
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
## Design Decisions
|
|
100
|
+
|
|
101
|
+
**Distillation over raw indexing.** Raw session transcripts are mostly noise. The system
|
|
102
|
+
uses Claude Haiku to extract *learnings* and discards the rest.
|
|
103
|
+
|
|
104
|
+
**One insight per embedding.** Each learning is a single, self-contained insight. Small
|
|
105
|
+
chunks retrieve with higher precision than paragraph-level chunks.
|
|
106
|
+
|
|
107
|
+
**Project affinity + recency decay.** Search results are ranked by vector similarity,
|
|
108
|
+
decayed for age, and boosted by usage frequency.
|
|
109
|
+
|
|
110
|
+
**Don't index what Claude already knows.** Generic programming knowledge is filtered out
|
|
111
|
+
during distillation. Only project-specific insights are stored.
|
|
112
|
+
|
|
113
|
+
## Development
|
|
114
|
+
|
|
115
|
+
```bash
|
|
116
|
+
uv sync
|
|
117
|
+
uv run pytest
|
|
118
|
+
uv run crowd-control --help
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
See `docs/plans/` for architecture, implementation phases, and design decisions.
|