Login Register
tire.kicker

tire.kicker / How I AI.md

Last active 5 months ago

Like 0

tire.kicker revised this gist 7 months ago · aa0c62b

No changes

tire.kicker revised this gist 7 months ago · 3965e3d

1 file changed

How I AI.md renamed to 000 How I AI.md

File renamed without changes

tire.kicker revised this gist 7 months ago · f1bfbbd

No changes

tire.kicker revised this gist 7 months ago · 04437a0

8 files changed, 2516 insertions

AGENTS.md (file created)
@@ -0,0 +1,57 @@
1 + # Python Environment And Package Policy
2 +
3 + Use `uv` for all Python workflows in this repository.
4 +
5 + ## Rules
6 + - Always run Python commands with `uv run`.
7 + - Always add dependencies with `uv add`.
8 + - Use `uv venv` for virtual environment setup/management.
9 + - Do not use `pip`, `pip3`, `python -m pip`, `virtualenv`, or `python -m venv`.
10 + - Do not install dependencies outside `uv`.
11 +
12 + ## Examples
13 + - Run app: `uv run python main.py`
14 + - Add runtime dependency: `uv add requests`
15 + - Add dev dependency: `uv add --dev pytest`
16 +
17 + # Test Coverage Policy
18 +
19 + Use `pytest-cov` via `uv` for coverage checks.
20 +
21 + ## Rules
22 + - If coverage flags are needed and `pytest-cov` is missing, install it with `uv add --dev pytest-cov`.
23 + - For the workspace package, install coverage tooling with `uv add --package geomrf-engine --dev pytest-cov`.
24 + - Run coverage with `uv run pytest ... --cov=...`.
25 + - Because both root and `geomrf-engine` use a `tests` package name, run coverage in two passes and combine reports instead of a single mixed pytest invocation.
26 +
27 + ## Coverage command pattern
28 + - Orchestrator pass: `COVERAGE_FILE=.coverage.orch uv run pytest tests --cov=satsim_orch --cov-report=`
29 + - Geo engine pass: `COVERAGE_FILE=.coverage.geomrf uv run --package geomrf-engine pytest geomrf-engine/tests --cov=geomrf_engine --cov-report=`
30 + - Combine/report: `uv run coverage combine .coverage.orch .coverage.geomrf && uv run coverage report -m`
31 +
32 + # OMNeT++/INET Environment Policy
33 +
34 + Use `opp_env` for OMNeT++/INET install and environment management in this repository.
35 +
36 + ## Rules
37 + - Use `opp_env` to install/manage OMNeT++ and INET versions.
38 + - Do not rely on ad-hoc/manual OMNeT++ or INET installs for project workflows.
39 + - Keep OMNeT++/INET version selection pinned and reproducible across dev and CI.
40 +
41 + ## Scope boundary
42 + - Python dependency and execution workflows remain `uv`-managed.
43 + - OMNeT++/INET toolchain workflows are `opp_env`-managed.
44 +
45 + # Legacy Code Reuse Policy
46 +
47 + If functionality from `old_code/` is needed:
48 + - Do not import or execute from `old_code/` directly.
49 + - Copy the required snippet(s) into a new file under the active codebase.
50 + - Adapt and maintain the copied code in the active module only.
51 +
52 + # Sandbox / Network Restriction Policy
53 +
54 + If a task is blocked by sandbox or network restrictions:
55 + - Stop immediately and do not spend tokens repeatedly trying to bypass restrictions.
56 + - Clearly tell the user that we are in a sandbox-restricted environment.
57 + - Ask the user for permission before attempting any sandbox breakout or elevated access.
ARCHITECTURE.md (file created)

Diff is too large to be shown

How I AI.md (file created)
@@ -0,0 +1,63 @@
1 +
2 +
3 + # Smol Example:
4 +
5 + ### ChatGPT Web:
6 + _<After workshopping the specs/requirements for a while...>_
7 +
8 + > Write an extremely detailed implementation doc for the streaming version and th apis . We are only looking at geometry rf engine right now . We need to be able to hand the doc you make off to an LLM to code the geometry enginer API up from the existing python code. Make it so . Extremely detailed. Markdown checkboxes for each discrete task `- [ ]` so the AI can mark them off with an X as they complete
9 +
10 +
11 + The codex-cli can start working on the output `TASKS_GEOENGINE.md`.
12 +
13 +
14 + # Implementing component 3 (of 4):
15 +
16 +
17 + ### ChatGPT Web:
18 +
19 + I pasted in all the `TASKS_*.md` the AI coder has produced so far, so the web planner has an idea of what was done. (If we didn't have access restrictions, the web version could just access the git repo).
20 +
21 + > Okay, here are the markdown taskfiles of what we've got done so far. We build geo engine and orchestrator . <extraneous details omitted> I need you to write a very detailed TASKS_IMNET.md file that deals with the imnet++ inet part and how it interacts with the other two systems as they exist . Write it as a markdown checklist - [ ] so the ai can cross items off as it writes them . Go .
22 +
23 +
24 + This produces TASKS_ORCHESTRATOR.md
25 +
26 +
27 + ### Codex CLI:
28 +
29 + > Check over TASKS_ORCHESTRATOR.md It was written without knowledg of the actual current implementation. Let me know if it looks good for ARCHITECTURE.md and if it is compatible with what has been done so far in TASKS_GEO_ENGINE.md We have only tried to make a gEO
30 + engine so far. no edits ,just check the TASKS_ORCHESTRATOR.md makes sense.
31 +
32 +
33 + ```
34 + Overall verdict: it is mostly aligned with ARCHITECTURE.md and broadly compatible with the Geo engine work, but the 3 medium/high items above should be clarified before implementation so the orchs estrator doesn’t encode wrong assumptions.
35 + ```
36 +
37 + This step is super important! I need to make sure the plan we thought of actually makes sense with what is happening on the ground.
38 +
39 + > Can the misaligned items be easily solved? Is there a moslty obvisous right answer to them ? If so tell me the gravious solutions, or show me my optiosn if there s a fork or hard choice
40 +
41 + _<More workshopping of differenes between web and implementation. The web has the pdf source documents and better web search, and has unlimited usage, so I did planning there>_
42 +
43 +
44 + ### Codex CLI:
45 +
46 + > @AGENTS.md You task is to implement the geometry engine defined in @TASKS_GEO_ENGINE.md . After completing each task, mark it off with an x (`- [x]`) so its markdown checkbox so there is an external record of what has been done. If plans change, then modify the task list appropriately. The overall high level architecture of the program is in @ARCHITECTURE.md . Go .
47 +
48 + This is where the magic happens! We have thought through our API and have developed a test plan, and a development plan. Now the AI can develop the code and test the API via the test suite to ensure its correct.
49 +
50 + ---
51 +
52 + Overall Advice:
53 +
54 + - Think about your inputs/outputs/dependencies beforehand.
55 + - When the AI screw ups hallucinates, or does something silly, you can make a note in AGENTS.md to do the right thing instead.
56 + - Force the AI to use as many deterministic static tools as possible:
57 + - Strict Type Checking (Use Rust instead of C, Typescript instead of Javascript, Python with Type Annotations instead of without)
58 + - Linters
59 + - Code Format Tools
60 + - Unit/Integration tests
61 + - Have the AI write as many tests as possible of what you want the program to do
62 +
63 + - If you want the AI to "one-shot" (i.e., autonomously code something complex for a while without supervision and get a good result), then you need to give it as much test input/output behaviour as possible, so it can keep checking against the "proper" results without your guidance.
README.md (file created)
@@ -0,0 +1,17 @@
1 + # SatSim docs index
2 +
3 + Primary design and task documents:
4 +
5 + - `ARCHITECTURE.md`
6 + - `TASKS_GEO_ENGINE.md`
7 + - `TASKS_IMNET.md`
8 + - `TASKS_ORCHESTRATOR.md`
9 + - `TASKS_TESTSUITE_GEOENGINE.md`
10 +
11 + Locked design decisions (2026-02-18):
12 +
13 + - Control-plane tick authority is `StreamLinkDeltas` (streaming-driven orchestration).
14 + - Event stream alignment is being standardized with request `dt`/`selector` and event `tick_index`.
15 + - Orchestrator error handling includes `NOT_FOUND`, `INVALID_ARGUMENT`, `FAILED_PRECONDITION`, and `RESOURCE_EXHAUSTED`.
16 + - Scenario translation to Geo/RF `ScenarioSpec` is fail-fast.
17 + - Python workflows are `uv`-managed; OMNeT++/INET workflows are `opp_env`-managed.
TASKS_GEO_ENGINE.md (file created)

Diff is too large to be shown

TASKS_IMNET.md (file created)

Diff is too large to be shown

TASKS_ORCHESTRATOR.md (file created)

Diff is too large to be shown

TASKS_TESTSUITE_GEOENGINE.md (file created)
@@ -0,0 +1,62 @@
1 + # Geometry/RF Engine Test Suite Plan
2 +
3 + This checklist tracks the work to build and verify a comprehensive RPC-focused test suite for `geomrf-engine`.
4 +
5 + ## 0) Deliverables
6 +
7 + - [x] Add a dedicated gRPC service test module that exercises all six RPCs.
8 + - [x] Validate success + error-path behavior for lifecycle and streaming RPCs.
9 + - [x] Produce an updated coverage report and capture gaps.
10 + - [x] Keep this checklist updated as tasks are completed.
11 +
12 + ## 1) Baseline and scope
13 +
14 + - [x] Confirm current tests/coverage baseline before adding new RPC tests.
15 + - [x] Confirm test scenario strategy (deterministic helper scenario; compatible with 027 overhead-pass style TLE + GS setup).
16 +
17 + ## 2) Test infrastructure
18 +
19 + - [x] Add an in-process gRPC test harness (ephemeral port, async channel/stub, clean teardown).
20 + - [x] Add shared helpers for creating/closing scenarios from tests.
21 +
22 + ## 3) RPC lifecycle tests
23 +
24 + - [x] `GetVersion` returns expected identity/schema metadata.
25 + - [x] `GetCapabilities` returns expected limits and feature flags.
26 + - [x] `CreateScenario` success path returns `scenario_ref`.
27 + - [x] `CreateScenario` invalid spec path returns `INVALID_ARGUMENT`.
28 + - [x] `CloseScenario` success path returns `ok=true`.
29 + - [x] `CloseScenario` unknown scenario path returns `NOT_FOUND`.
30 +
31 + ## 4) Streaming RPC tests
32 +
33 + - [x] `StreamLinkDeltas` success path returns ordered batches with snapshot metadata.
34 + - [x] `StreamLinkDeltas` unknown scenario path returns `NOT_FOUND`.
35 + - [x] `StreamLinkDeltas` closed scenario path returns `FAILED_PRECONDITION`.
36 + - [x] `StreamLinkDeltas` invalid time parameters return `INVALID_ARGUMENT`.
37 + - [x] `StreamEvents` success path returns well-formed events for the test scenario.
38 + - [x] `StreamEvents` filtered path validates event filtering behavior.
39 + - [x] `StreamEvents` unknown scenario path returns `NOT_FOUND`.
40 + - [x] `StreamEvents` closed scenario path returns `FAILED_PRECONDITION`.
41 +
42 + ## 5) Execution and coverage
43 +
44 + - [x] Run full test suite and ensure all tests pass.
45 + - [x] Run coverage scoped to `geomrf_engine`.
46 + - [x] Verify `server.py` and stream/event modules are covered by tests.
47 + - [x] Document final coverage numbers and remaining gaps.
48 +
49 + ## 6) Results summary
50 +
51 + - [x] Test count: `20 passed`.
52 + - [x] Coverage total (`geomrf_engine`): `85%` (`820` statements, `120` missed).
53 + - [x] Core RPC implementation coverage: `server.py` at `79%`, `streaming/events.py` at `96%`, `streaming/backpressure.py` at `80%`, `util/logging.py` at `92%`.
54 + - [x] Remaining notable gaps captured for follow-up: evaluator branch coverage (`56%`) and delta-threshold branch coverage (`71%`).
55 +
56 + ## 7) v1.1 follow-up (event alignment)
57 +
58 + - [ ] Add `StreamEvents` alignment tests for request `dt` semantics (`default_dt` fallback + invalid-range rejection).
59 + - [ ] Add selector-parity tests ensuring event selection mirrors `StreamLinkDeltas` selection.
60 + - [ ] Add assertions that every emitted `EngineEvent` carries `tick_index`.
61 + - [ ] Add cross-stream alignment test: same window/dt/selector for events+deltas yields consistent tick mapping.
62 + - [ ] Extend error-path coverage for new event request fields.