# тест11

аылаоыдлв. k.kokush@vtorum.net geser.space  аоывлд. аыол 😱 ралыораолывар 😀 ы ролаыраолыар ывлраыовларыол 🍏П
аываыаы😀олфыалооыловоробейоарывол😂ссолфрф влофврфловролфрвф 26.08.2026 19:45 Konstantin Kokush k.kokush@vtorum.net geser.space 5.32.1 Konstantin Kokush 
06:52 😀 🔒🔫🔓

27.08.2026 07:47 fdklshflkasjfklsdf Konstantin Kokush

[Weekly report Ainergy 24\.08\.26 v1 \(1\)\.docx](https://notes.vtorum.net/api/public/web/%D1%82%D0%B5%D1%81%D1%8211-139ed49c/assets/150a6525-7115-4ff2-81b9-31e567681832/raw)

В странице тест11 Воробья нет

Воробей есть!!!

# Vtorum repository workflow

- Work from this Git repository; do not treat release archives as the working tree.
- Preserve unrelated user changes and inspect git status before editing.
- After code changes, run the relevant tests, typecheck, and release/security guards.
- Finish completed changes with a local Git commit unless the user explicitly asks not to commit.
- For every deployable change, prepare an executable macOS script that copies the release to the Vtorum server and performs the deployment with one command.
- Do not run the production deployment unless the user explicitly requests it.
- Never commit .env, credentials, SSH keys, database dumps, or production secrets.
## Autonomous execution / permission prompts

- Do not ask the user for permission or confirmation before taking actions needed to complete the task, including local edits, file operations, tests, typechecks, builds, Git commits, diagnostics, SSH/SCP operations, log inspection, Docker commands, migrations, database writes, service restarts, and other standard or one-off server actions.
- The only action that requires explicit user confirmation is running the production deployment itself. Preparing, validating, packaging, and transferring a deployment package do not require confirmation.
- If an action is destructive or irreversible, first create an appropriate backup or use the safest reversible method available, then proceed without interrupting the task for confirmation.
- Do not pause merely to announce the next action. Continue working until the requested result is verified or a genuine technical blocker is reached.
## Progress reporting

- Keep the user continuously and meaningfully informed during technical work. Provide regular, detailed progress updates rather than waiting until the task is complete.
- Every progress update, status message, blocker report, and final completion message must begin with the current local time in HH:MM format, for example 20:38.
- Progress updates must state what was just done, what was found or verified, and what will be done next. Avoid vague messages such as “working on it”.
- Continue working after each progress update. Do not treat a status message as a stopping point unless a genuine technical blocker has been reached.
## Shell usage / avoiding unnecessary permission prompts

- Do not prefix Bash calls with cd "<repo path>" && when the working directory is already correct — the tool's cwd persists between calls in a session. Chaining cd with && turns a plain read-only command (grep/find/ls/cat/etc., which are normally auto-approved) into a compound command that no longer matches the auto-allow fast path, forcing a permission prompt every time. Just run the command directly.
- When a task requires several remote/server steps (SSH, scp, docker exec, running a migration script, checking logs), bundle them into one Bash call — e.g. a single ssh host 'set -e; step1; step2; step3' or one heredoc script — instead of issuing one Bash call per step.
- Structure commands to use existing auto-approved paths whenever possible. Do not ask the user to approve individual commands; only stop immediately before the production deployment when explicit confirmation has not already been given.
## Vtorum UI design system

- Every new button in Vtorum must use the existing Vtorum button design system and established button classes/components. Do not ship browser-default buttons or one-off local button styling.
- Use the established action hierarchy: primary actions use the Vtorum primary style, secondary/repeat/test/sync actions use the Vtorum secondary style, and destructive actions use the Vtorum danger style.
- If a needed button variant does not exist, extend the shared Vtorum design system first and then reuse it. Do not solve this with isolated page-specific CSS.
- New interactive media controls, including audio/video player buttons, must visually follow the same Vtorum design language, brand color #0CA8AE, focus treatment, hover/disabled states, sizing, radii, and typography.
## Development speed and token efficiency

- Start from the persistent Git working tree, never from a previously generated release ZIP. Release archives are outputs only.
- Before reading large files, locate the exact symbol, component, route, test, or CSS selector with rg, git grep, or a targeted file search. Read only the relevant ranges and direct dependencies.
- Prefer git diff -- <paths>, sed -n '<start>,<end>p', head, tail, and targeted grep over printing complete large files or logs.
- Do not repeat repository-wide exploration after the relevant files and relationships have already been identified. Reuse established context and architecture notes.
- Make the smallest coherent change that satisfies the request. Avoid unrelated refactoring, formatting churn, dependency upgrades, or architectural rewrites unless they are required.
- Do not create or modify release infrastructure, deployment scripts, Docker structure, test architecture, or project-wide tooling when the task only asks to update instructions, documentation, configuration, or one isolated feature.
- When the requested scope is ambiguous, infer the narrowest reasonable scope from the user's wording and existing context. Do not silently broaden the task.
## Efficient testing workflow

- After an edit, first run the narrowest relevant test or guard for the changed behavior.
- If that passes, run directly related tests and typechecks. Run the complete historical test suite only before a release, when shared infrastructure changed, or when the user explicitly requests it.
- When a test fails, rerun only the failed test after the first correction. Do not restart a full Docker build until the targeted failure is resolved.
- Do not create a new regression script for every cosmetic adjustment when an existing functional test can be extended clearly.
- Regression tests must verify observable behavior, public contracts, or essential properties. Do not bind tests to release numbers, comments, exact private function names, exact source ordering, or literal Dockerfile command chains unless those details are the contract being tested.
- Write assertions with short explicit failure messages. Do not pass an entire large source file as the assertion value when failure would print hundreds of kilobytes into the log.
- Keep local verification and Docker verification aligned. Before packaging, run the same release-critical checks that the Docker build will execute.
- Do not claim runtime behavior is verified when only static guards or typechecks were run. State precisely what was verified.
## Build and deployment efficiency

- Preserve and reuse package-manager and Docker BuildKit caches. Do not clear caches as a routine troubleshooting step.
- Order diagnostic work so inexpensive checks happen first: syntax and targeted guards, then typecheck, then build, then Docker image, then runtime smoke tests.
- Create a release archive only after targeted tests and release checks pass. Do not send intermediate or knowingly unverified archives to the user.
- Every corrected package must have a new unique version and filename. Never overwrite or republish a previous archive name.
- Before delivering an archive, extract it into a clean temporary directory and verify its root layout, installer path, executable bit, version consistency, and release-critical tests.
- Keep production deployment separate from preparation. Building, verifying, packaging, copying, and preparing rollback do not require confirmation; switching production to the new version does.
- Immediately before production deployment, report the version, backup/rollback plan, and exact action requiring confirmation.
- After deployment, run focused smoke tests for health, reported version, main UI/API availability, and the changed feature. If deployment validation fails, use the prepared rollback instead of improvising on production.
## Logs and diagnostics

- Capture verbose build and deployment output in a log file. In progress messages, report only the failing step, exit code, concise error, and the relevant surrounding lines.
- Do not paste full minified bundles, complete CSS files, full dependency installation logs, or repeated Docker output unless the omitted content is necessary to diagnose the failure.
- When asking the user for a log, request one complete diagnostic file or a precise range from the first failing step through the final error, not multiple piecemeal fragments.
- When producing diagnostic scripts, make them terminate after collecting the required evidence. Do not leave indefinite watchers running unless continuous monitoring was explicitly requested.
## Release discipline

- Follow semantic versioning for Vtorum releases: patch changes increment the third number, medium changes increment the second, and major changes increment the first.
- Update all version-bearing files consistently and verify synchronization before packaging.
- For deployable Vtorum work, provide one uniquely named ZIP and one installation command for macOS. Do not provide SHA-256 or checksum files.
- Preserve .git in the local repository synchronization, create the local commit with author email root@vtorum.net, and never push unless the user explicitly requests it.
- Deployment scripts must rotate /opt/backups/vtorum-pre-*, retaining only the five newest backup directories.
- Do not include an interactive confirmation inside the installer. The conversational confirmation immediately before production deployment is the only required approval.
- Development/deployment agent architecture is documented in docs/DEVELOPMENT_AGENTS_ARCHITECTURE.md; preserve its Git synchronization and trust-boundary invariants when changing agent code.

![](https://notes.vtorum.net/api/public/web/%D1%82%D0%B5%D1%81%D1%8211-139ed49c/assets/8bb14c77-b3a2-4a23-9234-ba706fee632e/raw)

![](https://notes.vtorum.net/api/public/web/%D1%82%D0%B5%D1%81%D1%8211-139ed49c/assets/7be899f7-c09d-418a-8c83-e9b67f68280a/raw)

![](https://notes.vtorum.net/api/public/web/%D1%82%D0%B5%D1%81%D1%8211-139ed49c/assets/0646c258-6853-401f-9c77-a651bb248d91/raw)

![](https://notes.vtorum.net/api/public/web/%D1%82%D0%B5%D1%81%D1%8211-139ed49c/assets/7d5e60bb-5243-46c5-8755-5ebfec15f907/raw)

Заявка на интеграцию с B2B API Лемана ПРО