Canonical application name: LlamaSrv; Python package: llamasrv; CMDB subtype: Application.
Application metadata lives in llamasrv/constants/DLlamaSrv.py.
This project uses pinned BMForge Codex skills. These are project-owned copies, not live imports from BMForge or another application.
Before the first BMForge-related edit in a Codex session, run the read-only, offline update check from the repository root:
python3 .agents/bmforge/manage.py check --project .
If this project’s policy prohibits all Git commands, use the alternative:
python3 .agents/bmforge/manage.py verify --project .
verify checks only local pinned-skill and manager hashes, with no Git, network or writes; it does not check whether newer upstream skills exist.
The check reads a clean local BMForge main checkout at ~/.cache/bmforge-upstream (override with BMFORGE_SOURCE or –source). It never fetches or clones. Refresh that checkout separately with ‘git pull –ff-only’, outside this check. “CURRENT” means current as of the reported cached source revision, not necessarily the newest GitHub commit. Report available changes or an unavailable check to the user. Do not apply updates, reinstall skills, or replace approved technologies without explicit user authorization. Continue using the pinned skills unless instructed otherwise.
Read .agents/skills/bmforge-project/SKILL.md for architecture. Every new app
also follows the pinned bmforge-constants, bmforge-localization and
bmforge-installation skills: centralize programmatic identifiers, prepare
English localization keys from its first user-facing feature, and implement
the installation lifecycle for the actual application before the first release.
Add translations only when requested, never by guessing. Invoke other
components as needed.
Follow each selected skill’s local
references/specification.md and approved module inventory. Never invent another
framework, database driver or plotting library as a shortcut.
Component selection and application-specific behaviour belong to this project’s requirements. A pinned skill is an instruction bundle, not executable app code.
For applications with more than one service, create an executable
scripts/services supporting start and stop. Run the application’s
start/stop commands sequentially in an explicit order. Keep it simple;
no dependency awareness is required.
Implementation authorization gate: discussion, brainstorming, design and proposed specifications do not authorize implementation. Read-only investigation is permitted, but do not modify project files (including code, tests, configuration or documentation), install dependencies or perform other mutating work until the user explicitly authorizes the agreed scope. A direct request to implement or fix counts; no magic words are required. Once authorized, complete that scope, its tests and its changelog without asking about every file. Pause for unapproved dependencies, architecture or material scope expansion. Permission to implement does not authorize commits, pushes, releases or deployments.
For EVERY completed logical change, including small code, tests, documentation,
configuration and maintenance work, update CHANGELOG.md under the single
## [Unreleased] heading before reporting completion or committing. Do not
wait for the release. Add or refresh one ### Summary for each meaningful
feature, fix or operational improvement, even if only one change has occurred.
Maintain one Summary heading per section. Follow the pinned
.agents/skills/bmforge-project/references/changelog-maintenance.md guide.
Bootstrap provided scripts/new-release.sh with metadata, changelog and
deployment-disabled install/upgrade/uninstall stubs. Complete and test these
stubs through bmforge-installation once the application topology is known.
Every successful installation must create the application-owned BASE_DIR and
last-successful .deployment-version, even for a client or custom library.
Do not run release or deployment tools, commit, tag or push without explicit
user authorization. This repository already has local main, dev, and feat/maint-0.1.0
branches. Preserve its attached BMForge mode and existing refs; do not run
init or setup-branches. Use the prepared release tooling only after
the user separately authorizes a release.
Read the pinned project’s release-setup and creating-a-release references
before release work.