TL;DR

ადმინი — ცალკე React 19 SPA, ხელმისაწვდომი მხოლოდ admin-როლისთვის. მართავს cross-workspace რესურსებს: სისტემურ პერსონებს, promt-რეცეპტებს, LoRA-მოდელებს, job-ების რიგს, Vast.ai instance-ებს, provisioning-წესებს, ბილინგს, აუდიტს. მთავარი ახალი ფიჩა — Plan-100 Control Plane Console კოორდინატორით/რანერით/რეკონსილერით და shadow-tables-ით cutover-ისთვის.

ადმინის მიმოხილვა

GoraGen-ის ადმინი — ეს ოპერაციული დისპეტჩერია. მისი მეშვეობით პლატფორმის გუნდი ხედავს, რა ხდება მთელ პროდუქტში ერთდროულად: რამდენი GPU არის ნაქირავები, რომელი job-ები ჩარჩა, რომელი მომხმარებლები ხარჯავენ ყველაზე მეტს, რომელი მოდელები მუშაობს ცუდად.

shell — AdminShell.tsx გვერდითი პანელითა და keyboard shortcut-ებით სწრაფი ნავიგაციისთვის.

Dashboard

მთავარი ეკრანი — KPI და live-მეტრიკები:

• აქტიური job-ები (ტიპებად: video, storyboard, kling, lora_training)
• რიგის სიღრმე და საშუალო lead time
• შეცდომების მთვლელი ბოლო 5/15/60 წუთში severity-ფილტრით
• მიმდინარე Vast.ai instances და მათი მდგომარეობა (booting / ready / running / cancelling / destroyed)

/admin/system/workers-health-ის გავლით მონიტორდება heartbeat-loop workers-კონტეინერიდან — თუ ბოლო heartbeat 60 წამზე ძველია, dashboard-ზე ანთდება ალერტი «workers down».

მომხმარებლები

/admin/users — მომხმარებლების browser. user_id-ზე დაჭერით — დეტალები: workspace, გენერაციის ისტორია, კრედიტის ბალანსი, daily-spend პროფილი, plan, ბოლო login-ების IP-ები.

ადმინს შეუძლია:

• მომხმარებლის plan-ის შეცვლა (Free → Starter → Pro)
• ხელით კრედიტების დამატება/ჩამოწერა
• Impersonate (cookie impersonated_by=:admin_id დროშით) — საჩივრების («ჩემთან არ მუშაობს X») გასარჩევად

ყველა ეს მოქმედება იწერება domain_events-ში და ჩანს compliance-ში აუდიტისთვის.

Personas / Presets / Workflows

სამი ცალკე CRUD-განყოფილება პლატფორმის კონტენტ-«ხერხემლისთვის»:

• /personas — სისტემური პერსონაჟები. თითოს აქვს lookbook (12+ კადრი), preset-ები (კამერა, ფონი, განათება), LoRA-მოდელების სია.
• /presets — promt-შაბლონებისა და კამერის მოძრაობების ბიბლიოთეკა.
• /workflows — ComfyUI-გრაფების შაბლონები. შაბლონი შეიძლება მიებას მოდელს (WAN, Hunyuan, LTX) და გამოიყენებოდეს renderer-ის მიერ.

Tasks

/admin/tasks — job-რიგის console. ოთხი ჩანართი: queued / live / recent / failed.

კონკრეტულ job-ზე დაჭერით — სრული დეტალები: workspace, user, instance, შესასვლელი პარამეტრები, შესრულების ლოგი, პროგრესის WS-შეტყობინებები, Gemini-ის შეფასება, საბოლოო ღირებულება. fail-ის შემთხვევაში — stack-trace Sentry-event-id-ით.

live-დან შესაძლებელია გაუქმება (graceful — ვაძლევთ მიმდინარე იტერაციას დასრულების შესაძლებლობას, არ ვუშვებთ შემდეგს). failed-დან შესაძლებელია გადატვირთვა (ახალი job იმავე პარამეტრებით).

Instances

/admin/instances — Vast.ai instance browser. თითო instance:

• offer_id, image, region, ფასი $/საათში
• მდგომარეობა (booting / ready / running / cancelling / destroyed)
• მიმდინარე job (თუ არსებობს)
• ღირებულება გაშვების დაწყებიდან
• ღილაკები terminate / SSH-connect / re-init

ყველა ხელით ოპერაცია instance-ებთან ახლა მიდის Control Plane-ით (იხ. ქვემოთ), და არა ადრე — Vast API-ის პირდაპირი გამოძახებით.

LoRA dashboard

/admin/lora — cross-workspace ხედი ყველა LoRA-სწავლების. თითოზე:

• სტატუსი (preparing / captioning / training / validating / done / failed)
• პროცენტული პროგრესი, ETA
• ლინკი validation-grid-ზე (შედეგის გადახედვა)
• ღირებულება, ხანგრძლივობა

ადმინს შეუძლია ჩარჩენილი სწავლების მოკვლა, failed-ამოცანის გადატვირთვა, kohya_ss-ის ლოგის ნახვა.

System

/admin/system — ადმინის ტექნიკური ნაწილი, გაყოფილია ქვე-ჩანართებად:

• audit — ადმინ-მოქმედებების ლოგი
• health — გაფართოებული health-გვერდი (Phase 9): workers heartbeat, DB latency, disk usage, queue depth
• provisioning — ავტო-provisioning-ის წესები (როდის ქირაობს პლატფორმა ახალ instance-ს, როდის ხურავს)
• spend — ფინანსური შეჯამება GPU-საათებითა და API-გამოძახებებით Anthropic / Gemini / Kling-ისთვის
• events — Phase 9 domain events feed (append-only, ბოლო 1000 ივენთი) JSON-მოდალით თითოზე

Plan-100 Control Plane Console

/admin/system/control-plane — ცალკე გვერდი კოორდინირებული provisioning-სისტემის სამართავად.

ეს Vast API-სთან პირდაპირი მუშაობიდან გადასვლაა ორკესტრაციის მოდელზე, სადაც ადმინსა და Vast-ს შორის დგას სამი loop:

• Coordinator — კითხულობს instance_requests-ს (provisioning-ის განცხადებებს), ამოწმებს parallel-limits-ს, velocity-guard-ს, ინსერტავს provision_attempts-ში.
• Runner — იღებს claimed attempt-ებს, იძახებს scripts/vast_provision.ensure_instance(...)-ს, ადებს terminal reducer-ს.
• Reconciler — N წამში ერთხელ სკანერავს stale lease-ებს, ძალით ხურავს cancelling-ში ჩარჩენილებს, ათავისუფლებს destroyed instance-ებს.

სამივე — leader-elected provision_leader ცხრილით. თუ ლიდერის შემცველი კონტეინერი კვდება, მეორე (თუ არსებობს) იჭერს ლიდერობას 60 წამში.

გვერდზე:

• სამი loop-ის live-სტატუსი (running / lost / draining)
• Observability მეტრიკები: 7 ციფრი (active requests, queued attempts, success rate, etc.)
• Pause ღილაკი — emergency-დროშა, რომელიც ხურავს სამივე loop-ს 30 წამში
• Resume ღილაკი — იხსნის emergency-pause-ს

გადახურვის ქვეშ — 5 cutover-დროშა 60-წამიანი TTL-cache-ით: workflow_spawn, auto_provisioner, parallel_limits, provisioning_cutover_admin_rule_action, provisioning_emergency_pause. შესაძლებელია flip ცალკე — მაგალითად, auto-provisioner-ის გამორთვა დანარჩენების შენარჩუნებით.

Settings

/admin/settings — სისტემური settings, runtime-tunable:

• maintenance_mode — გლობალური 503 არა-ადმინებისთვის
• prices — გენერაციის ფასები (per-shot, per-second, per-LoRA-train)
• retention — ვიდეოების, ივენთების, idempotency-key-ების შენახვის ვადები

settings-ის ცვლილება ერთბაშად ჩანს ყველა worker-ისთვის polling-ით ყოველ 60 წამში.

Events feed

Phase 9-მა შემოიტანა append-only domain_events. პლატფორმის თითო მნიშვნელოვანი ივენთი (ახალი user, ახალი job, provisioning-ის fail, plan-ის apgrade) იწერება ცალკე ხაზად ტიპით, აქტორით, payload-JSON-ით.

ადმინში /admin/system/events — რეაქტიული feed ფილტრებით ივენთის ტიპით, აქტორით, თარიღების დიაპაზონით. ორმაგი დაჭერა — მოდალი pretty-printed JSON-ით.

ეს ორ რამეს იძლევა: forensic-აუდიტი (რა მოხდა ბოლო 24 საათში) და event-source ინტეგრაციებისთვის (ივენთების გადაცემა გარე webhook-ებში webhook_dispatcher-ით).