cronekorkn/left4me
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
No description
432 commits 2 branches 0 tags 4.8 MiB
Python 79.9%
JavaScript 9.8%
HTML 6.2%
CSS 3.2%
Shell 0.8%
Find a file
mwiegand 307df9c23a
feat(files): migrate dialogs (new-folder, delete, conflict) to dialogs.js 
Step 3/12 of docs/superpowers/plans/2026-05-17-files-overlay-rewrite.md.

dialogs.js owns the three inline <dialog> modals that surround the
file manager:
  * #files-new-folder-modal — "+ folder" / mkdir prompt
  * #files-delete-modal — delete-confirm for files and folders
  * #files-conflict-modal — overwrite / keep-both / cancel choice

Pattern change: the legacy file used clone-and-rebind
(replaceWith(cloneNode(true)) + fresh addEventListener) to drop stale
state-bearing click listeners between dialog opens. dialogs.js replaces
that with a single delegated listener per dialog, reading per-dialog
state from module-scope nullable variables (conflictState,
deleteState, newFolderState). The state is set when the dialog opens
and cleared on the 'close' event so dismissals don't leave stale
references. Listener attaches once per page load.

Dialog opens go through window.modals.openInline()/closeInline()
instead of dialog.showModal()/close() directly, completing the inline-
modal convention from commit c51089d.

askConflict now resolves to "cancel" on any dismissal (Esc, backdrop,
programmatic close) thanks to the 'close' event handler — the legacy
version left the promise pending forever in those paths. Verified
live: closeInline() on an open conflict dialog resolves the pending
askConflict promise to "cancel".

Action-registry dispatch: dialogs.js registers "new-folder" and
"delete" handlers into __filesOverlay. Combined with editor.js's
registration of "new-file" and "edit" (Step 2), only "zip" remains in
the legacy click switch (pure URL navigation, no module dependency).

Cross-module exposure: askConflict moves from files-overlay.js to
dialogs.js; both set __filesOverlay.askConflict, but dialogs.js wins
by document order (it loads before legacy via the <script defer>
ordering in overlay_detail.html). The legacy upload + drag-drop call
sites switch from local askConflict() to window.__filesOverlay
.askConflict() — same shape, different lookup.

The orphaned newFolderDialog / conflictDialog / deleteDialog
declarations at the top of legacy are deleted; legacy no longer holds
references to those elements.

Numbers:
  files-overlay.js: 669 → 589 lines (-80)
  files-overlay/dialogs.js: 212 lines (new)
  Net: +132 lines. Growth is from the delegation/state-management
  scaffolding and module-header comments. The delete went lighter
  than the plan's ~150-line estimate because the new code is more
  carefully structured (less duplication across the 3 dialogs).

Verified live on /overlays/2 in Chromium:
  * 4 script tags load in order (core → editor → dialogs → legacy)
  * Registry has 10 keys; askConflict + withCollisionSuffix still set
  * "+ new folder" on overlay root → new-folder dialog opens with
    empty name input and "/" target label, closes cleanly
  * "✕" on a file row → delete-confirm dialog opens with the file's
    name displayed, closes cleanly
  * askConflict('a/b.txt') → conflict dialog opens with path shown
    - close via window.modals.closeInline() → resolves "cancel"
    - click [data-files-conflict-action="overwrite"] → resolves "overwrite"
    - click [data-files-conflict-action="keep-both"] → resolves "keep-both"
  * No console errors throughout
  * pytest still 573 passed, 1 skipped, 3 deselected

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-17 15:51:47 +02:00
deploy deploy/journalctl: anchor server log to current unit start 2026-05-15 23:04:53 +02:00
docs docs(files): errata — script tag lives in overlay_detail.html, not base.html 2026-05-17 15:02:21 +02:00
examples/script-overlays feat(l4d2-web): seed example script overlays from examples/script-overlays/ 2026-05-08 18:41:08 +02:00
l4d2host refactor(repo): uv workspace + hatchling + layout restructure 2026-05-15 22:04:29 +02:00
l4d2web feat(files): migrate dialogs (new-folder, delete, conflict) to dialogs.js 2026-05-17 15:51:47 +02:00
scripts feat(scripts): add scripts/dev-server.py for local UI smoke 2026-05-17 00:04:11 +02:00
.envrc chore(envrc): switch direnv from use uv to layout uv 2026-05-16 13:20:16 +02:00
.gitignore chore(gitignore): ignore .tmp/ scratch directory 2026-05-16 11:53:14 +02:00
.python-version refactor(repo): uv workspace + hatchling + layout restructure 2026-05-15 22:04:29 +02:00
AGENTS.md refactor(modals): consolidate modal.js + modal-router.js as inline/routed 2026-05-17 14:31:38 +02:00
cvar_list feat(editor-v2): vocab generator + cvar_list-derived JSON 2026-05-17 01:55:33 +02:00
pyproject.toml test(e2e): scaffold Playwright + live-server fixture 2026-05-16 21:00:45 +02:00
README.md refactor(repo): uv workspace + hatchling + layout restructure 2026-05-15 22:04:29 +02:00
uv.lock test(e2e): scaffold Playwright + live-server fixture 2026-05-16 21:00:45 +02:00

README.md

left4me

left4me is a local L4D2 server management platform with two planned components:

  1. l4d2host + l4d2ctl (host library + CLI)
  2. l4d2-web-app (Flask web app for users, blueprints, servers, jobs, and logs)

Status

Implementation plans remain the source of truth for architecture and task sequencing:

  • docs/superpowers/plans/2026-04-22-l4d2-host-lib-v1.md
  • docs/superpowers/plans/2026-04-23-l4d2-web-app-v1.md

Locked v1 Decisions

  • Naming is strictly l4d2 (not l4d).
  • Host library and web app are separate components.
  • Host CLI write commands are fixed to:
    • install
    • initialize <name> -f <spec.yaml>
    • start <name>
    • stop <name>
    • delete <name>
  • Host CLI read commands are available for the web/host boundary:
    • status <name> --json
    • logs <name> --lines <n> --follow/--no-follow
  • The web app calls host operations through l4d2ctl, not direct l4d2host imports.
  • Deployment uses /var/lib/left4me for runtime state, /opt/left4me for repository contents and the virtualenv, /etc/left4me for environment files, and global units under /usr/local/lib/systemd/system.
  • Overlay handling is directory-based; the web app populates each overlay (workshop downloads, managed-global refresh).
  • No lock manager, no rollback, no preflight checks in host library.
  • CLI propagates subprocess failures via stderr and return code.
  • delete on missing instance is no-op success.
  • Blueprint model (web app):
    • user-private in v1
    • servers are live-linked to blueprint
    • no per-server overrides
    • delete blueprint blocked when linked servers exist
    • blueprint changes apply on next action
    • server can reassign blueprint anytime

Planned Repository Layout

  • l4d2host/
  • l4d2web/
  • deploy/
  • docs/superpowers/plans/

Deployment

See deploy/README.md for the Linux test deployment contract, including the runtime user, target filesystem layout, systemd units, privileged helpers, sudoers rules, admin bootstrap, and overlay reference rules.

Local development

This repo is a uv workspace (l4d2host + l4d2web as members) with a committed uv.lock and a .python-version pinning Python 3.13 (matching the Debian Trixie production target).

One-time prereq: install uv (macOS: brew install uv; Linux: curl -LsSf https://astral.sh/uv/install.sh | sh — uv is not yet in Debian stable's apt).

  1. direnv allow once per fresh checkout (and after any .envrc change). .envrc uses use uv, which runs uv sync and activates .venv/ on cd.
  2. Without direnv: uv sync at the repo root creates .venv/, installs both workspace members editable, and pulls in dev deps (pytest) from the lockfile.
  3. Tests: uv run pytest (or just pytest once the venv is on PATH).

Tech Stack (planned)

  • Python 3.13+ (workspace uses uv + hatchling)
  • Typer, PyYAML, pytest
  • Flask, SQLAlchemy, Alembic
  • HTMX (vendored locally), custom CSS, SSE
  • systemd units, kernel overlayfs (mounted via the left4me-overlay privileged helper), steamcmd

Recommended Implementation Order

  1. Implement l4d2host plan first.
  2. Implement l4d2web plan second.
  3. Keep tests green task-by-task (TDD flow from plans).
  4. Keep commits small and aligned with plan tasks.

Contributing Notes

  • Follow plan task order unless explicitly re-planned.
  • Keep contracts above unchanged unless the user asks to change them.
  • Update plan docs when scope or behavior changes.