alexion/dev
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(obsidian): process inbox notes

Browse Source
This commit is contained in:
alexion
2026-09-15 09:44:36 -04:00
parent a73b59aa0a
commit 4b3ca27637
4 changed files with 53 additions and 140 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
docs/00 INBOX/ai/ariadne-project-goals.md
View File

@@ -1,68 +0,0 @@
# Ariadne project goals
Ariadne analyzes a local Ren'Py game install.
It extracts source, builds a source graph, and plans routes through target nodes.
## Privacy constraint
Do not write the target game's title in the monorepo.
Use `target game` or `Ren'Py game` in committed notes, code, and pull requests.
Keep title-specific paths and names in ignored local data only.
## Goal order
1. Unlock all Steam achievements.
2. Maximize Season 3 dialogue coverage.
3. Extend the same coverage work to Seasons 1 and 2.
## Steam achievements
Achievement unlocks appear in source as reachable calls.
The first planning target is every achievement grant node.
Ariadne needs to find each grant call and compute route conditions that reach it.
This is source-graph coverage over sparse semantic targets.
## Season 3 dialogue coverage
Season 3 exposes an in-game percentage for seen dialogue.
The stat computes Ren'Py dialogue-block coverage from persistent seen data.
For this game, dialogue blocks map mainly to unique `Say` statements.
Ariadne should target Season 3 `Say` nodes as coverage targets.
The in-game percentage gives a validation signal for Ariadne's coverage model.
Season 3 also rewards high coverage inside the game.
## Seasons 1 and 2 coverage
Seasons 1 and 2 lack the same in-game percentage display.
Ariadne can still compute source coverage for their dialogue nodes.
Validation for these seasons will depend on Ariadne's own model.
Persistent seen data can still help later.
## State model phases
The first phase ignores player state.
It asks which routes cover all targets from source alone.
A later phase reads existing player state.
It uses save files or persistent data to remove completed targets.
That phase produces a personalized plan for remaining achievements and dialogue coverage.
## Graph model
The source graph needs typed nodes for labels, jumps, conditions, menus, visual statements, dialogue, and achievement grants.
Menus and conditions require branch edges and merge edges.
Dialogue and visual nodes support route explanation.
Achievement and dialogue nodes become coverage targets.
## Near-term implementation direction
Keep extraction and decompilation generic.
Parse source into typed graph artifacts.
Add achievement grant nodes before broad route planning.
Add Season 3 dialogue nodes as the next coverage target set.

71
docs/00 INBOX/ai/steamcmd servers.md
View File

@@ -1,71 +0,0 @@
# SteamCMD servers
Use `modules.services.steamcmd` as the low-level runner for one SteamCMD server.
Create a game module under `configs/nixos/modules/services/games/` for each game.
The game module owns game-specific defaults and command-line flags.
The host owns deployment-specific paths, names, secrets, and network placement.
## Create a game module
1. Create `configs/nixos/modules/services/games/<game>.nix`.
2. Define options under `modules.services.games.<game>`.
3. Expose only values the host must choose.
4. Map those values to `modules.services.steamcmd`.
5. Set the Steam dedicated-server app ID in the game module.
6. Set the server executable in the game module.
7. Generate game-specific arguments in the game module.
8. Open the game's documented UDP ports in the game module.
Keep `modules.services.steamcmd` focused on shared SteamCMD behavior.
Do not put game-specific flags or port rules there.
## Configure a host
During validation, enable the game module directly on a host.
```nix
modules.services.games.valheim = {
enable = true;
steamDir = "/pikachu/data/steamcmd";
installDir = "/pikachu/data/servers/valheim/main";
stateDir = "/pikachu/media/games/servers/valheim/main";
serverName = "main";
password = "foobarbaz";
};
```
Use host paths for direct host deployment.
Use guest paths after the server moves into a guest.
## Deploy and test
1. Evaluate the host configuration.
```sh
nix eval .#nixosConfigurations.<host>.config.system.build.toplevel.drvPath --raw
```
2. Deploy the host.
```sh
deploy-to <host>
```
3. Check the game service.
```sh
sudo systemctl status <game>.service
sudo journalctl -u <game>.service -n 200 --no-pager
```
4. Check UDP listeners.
```sh
sudo ss -lunp | grep -E '<port>|<port-plus-one>|<game>'
```
5. Connect from the game client.
The Valheim server is ready after the log contains `Game server connected`.
It can spend time generating a new world before it accepts connections.

2
docs/00 INBOX/how to setup a steamcmd server.md → docs/02 notes/steamcmd server setup.md
View File

@@ -2,7 +2,7 @@
date-created: 2026-09-10 12:01
---
# How to set up a `steamcmd` server
# SteamCMD server setup
This note explains how to add a SteamCMD-managed game server to the NixOS configuration.

52
docs/03 wrk/ariadne.md
View File

@@ -6,6 +6,34 @@ These notes capture the design state from the Ariadne pipeline and Ren'Py AST di
Do not assume the implementation described here still exists in the Ariadne worktree. The pull request work was considered exploratory and should be dropped or redone cleanly.
## Product goals
Ariadne analyzes a local Ren'Py game install.
It builds a source graph and plans routes through target nodes.
Goal order:
1. Unlock all Steam achievements.
2. Maximize Season 3 dialogue coverage.
3. Extend dialogue coverage to Seasons 1 and 2.
Achievement unlocks appear in source as reachable calls.
The first planning target is each achievement grant node.
Season 3 exposes an in-game percentage for seen dialogue.
That percentage gives a validation signal for Ariadne's coverage model.
The first phase ignores player state.
It computes routes from source alone.
A later phase reads save files or persistent data.
It removes completed targets and plans remaining coverage.
## Privacy constraint
Do not write the target game's title in committed material.
Use `target game` or `Ren'Py game` in notes, code, commits, and pull requests.
Keep title-specific paths and names in ignored local data only.
## Core state model
Ariadne's core state should be graph-first. The current agreed shape is:
@@ -274,6 +302,30 @@ Treat that dump as a development surface until Ariadne documents a stable format
Route planning is out of scope for the first importer slice.
## Pipeline stage boundary
A library stage is a pure state transformation.
It receives committed `State` and stage-specific inputs.
It returns a new `State` with pending operations.
A CLI stage is a user-facing execution target.
It owns filesystem discovery, file reads, and stage orchestration.
It can deserialize Clew JSON by calling Ariadne library helpers.
`run_parse` receives already-deserialized Clew documents.
It does not discover files, read files, or deserialize JSON.
The runner applies pending operations after each library stage.
The next stage receives committed state with no pending operations.
`apply_pending` returns a new `State`.
It applies the pending batch atomically.
Invalid pending operations do not produce partial committed state.
The first implementation does not resume from serialized stage artifacts.
It also avoids a stage trait, shared context object, and stage invocation enum.
Give each stage function only the inputs it needs.
## Preparation output direction
Clew produces the preparation output for Ariadne.