vulyk-bootstrap

You are initializing VULYK for this repository. Follow bootstrap/interview.md exactly:

1. Interview. Ask the questions in the script in 3 batches (context -> conventions -> posture). With --quick in "$ARGUMENTS", infer answers from the repo (package files, CI config, lockfiles, README) and present them for one-shot confirmation instead.
2. Tailor the constitution. Fill the ## Profile block between the VULYK:PROFILE markers - it arrives blank because a profile copied from another repository is a confident lie, and every caste starts from it. Stack, runner, where source lives, test framework, commit convention, and the last row, which is the one that pays for itself: which configurations actually exist today, and what is deferred and until when. A reviewer that does not know this demands guarantees for deployments nobody has, and the blind acceptance gate cannot state the shape it judged against - both have cost real review rounds. Write it from what you verified in step 1, never from what a README claims. Set TOP_MODEL per the budget answer. Replace every row of the ## Commands table — the shipped rows are VULYK's own (shell/Python syntax checks) and are wrong for any other project; delete them along with the warning blockquote above the table. Use this project's real commands in their quiet form — find the flag that suppresses per-test/per-file chatter (--reporter=dot, -q, --silent, --quiet) rather than pasting the README's default invocation; that output is resent on every later turn. Verify each command actually runs, and if the project genuinely lacks one (no build step, no test runner), write that instead of inventing a plausible command — a verification that always exits 0 is worse than an admitted gap. Write path-scoped conventions into .claude/rules/<area>.md instead of bloating CLAUDE.md.
3. Prune the roster. Delete agents that cannot apply here (e.g. worker-test if the project has no test runner - and say so loudly), adjust tools lists to the stack. drone-acceptance is the one agent whose removal is never silent: if this project has no way to be run and observed, write that sentence into the summary. "Nothing here can check that the software does what was asked" is a fact the human should own deliberately, not a gap discovered later.
4. Build the map. Identify top-level modules. Dispatch drone-scout per module - batch up to 4 in parallel - and save each report as memory/map/<module>.md with a last-verified date. For very large repos (1000+ files), map breadth-first: top 8-12 load-bearing modules now, note the rest in memory/memory.md as unmapped territory.
5. Seed memory. Write memory/memory.md pointer index (<= 60 lines): map files, key wiki notes to create, verification commands, unmapped territory.
6. Seed wiki. Create 2-4 docs/wiki/ notes for the most load-bearing domains/invariants discovered during mapping (use templates/wiki-note.md).
7. Commit everything as vulyk: initialize hive for <project> and print a summary: tier examples for THIS codebase, the three-command loop, and any pruned agents.

Do not start any feature work. Bootstrap ends with the commit and summary.