RO
RAILSHOT.
Înapoi în sală

Railshot

AI deployment & operations platform

Implementarea unei aplicații web construite local în medii cloud și on-premises pregătite, apoi operarea ei.

O platformă AI de implementare și operare care duce o aplicație web construită local în medii cloud sau on-premises pregătite și o ține în funcțiune.

28 septembrie 2026 – 4 octombrie 2026 · Încheiat

Proiect de echipă · partea mea: planificarea și implementarea CI, clusterele CSP și interfața Ansible, operare, revizuirea codului și integrare în echipă

SoftBank Hackathon 2026 powered by KOREC & ProgateParticipant în preliminarii · selecția pentru finală va fi anunțată pe 26 octombrie 2026 (la 7 octombrie 2026)

  • Interfață webImplementat · hackathon
  • Server MCPImplementat · la distanță · local

Interfața web și agentul propriu al utilizatorului cer implementarea prin același API al produsului.

Produsul, de la o cerere de implementare acceptată, prin verificările CI și publicarea imaginii, până la configurația Git și lansarea Argo CD pe o țintă înregistrată și verificarea HTTPS publică. Succesul este înregistrat doar cu o revizie aplicată și o verificare publică; un rezultat care nu poate fi cunoscut rămâne unknown.

Un proiect trimis din interfața web sau dintr-un agent AI propriu conectat prin MCP trece prin pregătirea fișierelor de implementare, repararea eșecurilor, publicarea imaginii, lansarea în mediu și verificarea URL-ului public; după implementare, același ecran arată istoricul și jurnalele și gestionează actualizările, oprirea, reluarea și ștergerea. Un proiect de echipă.

Perioada de dezvoltare a competiției: 28 septembrie 2026 – 4 octombrie 2026

Interfața web și serverul MCP construite în timpul hackathonului. MCP-ul la distanță se autentifică prin OAuth pentru a trimite; folderele locale sunt trimise prin MCP-ul local.

Arhitectura produsului · desenată după căile de cod din commitul public 645e28a
Arhitectura produsului RailshotComponentele și conexiunile produsului Railshot. Interfața web, MCP-ul OAuth la distanță și un MCP local de pe computerul utilizatorului cer implementarea prin același API al produsului, care înregistrează un commit sursă și o rulare CI. CI decide prin verificări fixe și publică imaginile verificate în GHCR. Adaptorul CD aplică prin config Git și Argo CD doar când ținta înregistrată corespunde înregistrării de publicare, apoi verifică adresa HTTPS publică înregistrată și înregistrează rezultatul. Metricile sunt observație, separată de verdict.Utilizator în browserfolder · ZIP · URL GitHubClient MCPChatGPT · Codex · Clauderailshot-local MCPcomputerul utilizatorului · stdioGHCRimagini prin digestAI SDK providerCodex · Claude SDKDepozitul config Gitworkload.json înregistratURL HTTPS publiccale de health înregistratăPrometheusVM de control al operării · citireapps/dashboardinterfață web · istoric · Insightsagent/remote-mcp.jsOAuth MCP · deploy_repositoryapps/apivalidare · țintă · acceptare 202coadă de implementare · câte 3legarea rulării CI · observarecd.js · deployPublishedmetrics observerapi/product-store.jsstarea operației · legarea rulăriigitops/bridge.pyconfigurație de încredere · țintă înregistratăcommit · push · recitire de pe remotesincronizare Argo · observaresondă HTTPS publicăArgo CDApplication · verificare AppProjectapps/<tenant>/<app>commit sursă · trailererailshot-deploy.ymlbuclă · verificări de bază L0–L3reparare SDK · doar eșecuri reparabileaceleași verificări → pachet testatversiune · publicare în GHCR · legareClusterul de aplicații K3sworkload · ServicePlatforma Railshotcluster de operare · AWSGitHubdepozit privat apps · ActionsȚintă înregistratăcale publică per furnizor1 folder · ZIP · URL GitHub · Utilizator în browser → interfață web · istoric · Insights12același API al produsului · /api/v13 OAuth · deploy_repository · Client MCP → OAuth MCP · deploy_repository34același API al produsului5 încărcare ZIP · deploy_local_project · railshot-local MCP → validare · țintă · acceptare 20256 queued înregistrat · 202 · validare · țintă · acceptare 202 → starea operației · legarea rulării67 ordinea din coadă · starea operației · legarea rulării → coadă de implementare · câte 378starea implementării · istoric1source commit2workflow_dispatch3commitul trimis4cerere de reparare · condiționată5publicarea imaginilor verificate6rulare · citirea publicării7 failed · publication_unverified · legarea rulării CI · observare → starea operației · legarea rulării71images.json · spec · verdict · manifest2aplicare · țintă înregistrată3workload commit · push4revision5 sincronizare · observare · sincronizare Argo · observare → Application · verificare AppProject56aplicare7pull de imagine · digest8HTTPS health9 cale publică · URL HTTPS public → workload · Service910 succeeded · revision · URL · cd.js · deployPublished → starea operației · legarea rulării1011 unknown · necesită reconciliere · cd.js · deployPublished → starea operației · legarea rulării111interogare PromQL2scrape · probe3starea implementării · istoric4HTTPS health

Trimitere → acceptare

Interfața web, MCP-ul la distanță și MCP-ul local apelează același API al produsului, care înregistrează o cerere verificată ca queued și răspunde cu 202.

  1. Utilizator în browserfolder · ZIP · URL GitHubinterfață web · istoric · Insightsapps/dashboard

    Sursa și un mediu înregistrat sunt alese în interfața web.

  2. interfață web · istoric · Insightsapps/dashboardacelași API al produsului · /api/v1validare · țintă · acceptare 202apps/api

    Interfața web apelează API-ul produsului de pe aceeași origine.

  3. Client MCPOAuth · deploy_repositoryOAuth MCP · deploy_repositoryagent/remote-mcp.js

    MCP-ul la distanță se conectează prin OAuth și primește ca intrare un depozit GitHub public.

  4. OAuth MCP · deploy_repositoryagent/remote-mcp.jsacelași API al produsuluivalidare · țintă · acceptare 202apps/api

    Serverul MCP la distanță apelează același API de implementare prin clientul său API intern.

  5. railshot-local MCPîncărcare ZIP · deploy_local_projectvalidare · țintă · acceptare 202apps/api

    MCP-ul stdio de pe computerul utilizatorului arhivează un folder în ZIP și îl încarcă. Sesiunea lui nu este partajată cu sesiunea OAuth la distanță.

  6. validare · țintă · acceptare 202apps/apiqueued înregistrat · 202starea operației · legarea rulăriiapi/product-store.js

    Sunt verificate intrarea, ținta înregistrată, capacitatea și cheia de idempotență; operația este înregistrată ca queued și se răspunde cu 202. Un 202 înseamnă acceptat, nu implementat.

  7. starea operației · legarea rulăriiapi/product-store.jsordinea din coadăcoadă de implementare · câte 3apps/api

    Preluate în ordinea acceptării, în limita implementărilor concurente (implicit 3).

  8. starea operației · legarea rulăriiapi/product-store.jsstarea implementării · istoricinterfață web · istoric · Insightsapps/dashboard

    Interfața web și instrumentele MCP citesc aceleași înregistrări ale operațiilor. Ultima încercare și implementarea verificată curentă sunt afișate separat, iar o sarcină AI încheiată nu înseamnă o implementare reușită.

Verificări CI → publicarea imaginii

Codul de platformă fixat verifică commitul trimis, predă AI-ului doar eșecurile reparabile și publică doar imaginile care au trecut din nou aceleași verificări.

  1. coadă de implementare · câte 3apps/apisource commitcommit sursă · trailereapps/<tenant>/<app>

    Sursa trimisă devine un commit în depozitul privat apps (cu trailerele Railshot-Request și Railshot-Target), iar ramura este actualizată fără force.

  2. coadă de implementare · câte 3apps/apiworkflow_dispatchbuclă · verificări de bază L0–L3railshot-deploy.yml

    Cere o rulare cu tenant, app, source_commit și target_id. Dacă răspunsul se pierde, cererea nu este trimisă din nou; sunt căutate în schimb rulările pentru același commit.

  3. commit sursă · trailereapps/<tenant>/<app>commitul trimisbuclă · verificări de bază L0–L3railshot-deploy.yml

    Se face checkout doar pentru commitul trimis și pentru codul de platformă fixat (PLATFORM_REF).

  4. reparare SDK · doar eșecuri reparabilerailshot-deploy.ymlcerere de reparare · condiționatăAI SDK provider

    Este apelat doar pentru clase de eșec reparabile și se oprește când același eșec se repetă sau se atinge limita de încercări. Trecerea sau eșecul sunt decise de verificări, nu de LLM.

  5. versiune · publicare în GHCR · legarerailshot-deploy.ymlpublicarea imaginilor verificateGHCR

    După verificarea pachetului care a trecut verificările, aceleași imagini sunt publicate în GHCR. Nu se reconstruiește nimic.

  6. legarea rulării CI · observareapps/apirulare · citirea publicăriirailshot-deploy.yml

    O publicare contează doar când run id, source commit, ținta și aplicația corespund înregistrării acceptate.

  7. legarea rulării CI · observareapps/apifailed · publication_unverifiedstarea operației · legarea rulăriiapi/product-store.js

    Un eșec CI sau o publicare neverificată este înregistrată cu diagnostic și nu este transmisă către CD.

Aplicare → verificare publică

Aplică prin config Git și Argo CD doar când publicarea corespunde țintei înregistrate și înregistrează succesul doar după ce adresa HTTPS publică înregistrată este confirmată.

  1. versiune · publicare în GHCR · legarerailshot-deploy.ymlimages.json · spec · verdict · manifestcd.js · deployPublishedapps/api

    CD citește fișierele înregistrării de publicare printr-un loader de încredere. CI nu creează el însuși nicio resursă de cluster, URL sau succes de implementare.

  2. cd.js · deployPublishedapps/apiaplicare · țintă înregistratăconfigurație de încredere · țintă înregistratăgitops/bridge.py

    Rulează gitops/bridge.py cu configurația de încredere doar când aplicația și tenantul înregistrate corespund înregistrării de publicare.

  3. commit · push · recitire de pe remotegitops/bridge.pyworkload commit · pushDepozitul config Git

    Face commit doar pentru workload.json la calea înregistrată a unei ramuri dedicate, înregistrează mai întâi intenția de push, face push și recitește revizia de pe remote. Un push incert nu este repetat.

  4. Depozitul config GitrevisionApplication · verificare AppProjectArgo CD

    Revizia depozitului de configurație spre care indică Application din Argo CD.

  5. sincronizare Argo · observaregitops/bridge.pysincronizare · observareApplication · verificare AppProjectArgo CD

    Cere o sincronizare după verificarea AppProject; la observare doar citește, fără sincronizare.

  6. Application · verificare AppProjectArgo CDaplicareworkload · ServiceClusterul de aplicații K3s

    Aplică sarcina de lucru pe clusterul țintă înregistrat.

  7. workload · ServiceClusterul de aplicații K3spull de imagine · digestGHCR

    Descarcă digest-ul publicat. Un GHCR privat necesită o credențială de pull dedicată.

  8. sondă HTTPS publicăgitops/bridge.pyHTTPS healthURL HTTPS public

    Verifică doar adresa HTTPS de health înregistrată de operator, fără redirecționări, pentru 200 (și JSON-ul așteptat, dacă este setat).

  9. URL HTTPS publiccale publicăworkload · ServiceClusterul de aplicații K3s

    Calea publică (LB, NodePort, certificat) diferă în funcție de furnizor și de ținta înregistrată.

  10. cd.js · deployPublishedapps/apisucceeded · revision · URLstarea operației · legarea rulăriiapi/product-store.js

    Este înregistrat ca succeeded doar cu cd.deployed, o revizie, o verificare HTTPS publică reușită, momentul ei și un URL valid.

  11. cd.js · deployPublishedapps/apiunknown · necesită reconcilierestarea operației · legarea rulăriiapi/product-store.js

    Un rezultat care nu poate fi cunoscut rămâne unknown; aceeași aplicare nu este nici retrimisă, nici anulată.

Observație · nu verdictul

Metricile și sondele nu decid succesul implementării. Valorile lipsă, învechite și eșuate sunt afișate ca atare.

  1. metrics observerapps/apiinterogare PromQLPrometheus

    Citește seriile up, probe_success și Pod. Valorile lipsă, învechite sau eșuate sunt afișate în acea stare și nu sunt transformate niciodată în 0.

  2. Prometheusscrape · probeworkload · ServiceClusterul de aplicații K3s

    Scrape de exporter și sondă HTTP. Aceste metrici nu sunt folosite pentru a decide succesul implementării.

  3. starea operației · legarea rulăriiapi/product-store.jsstarea implementării · istoricinterfață web · istoric · Insightsapps/dashboard

    Interfața web și instrumentele MCP citesc aceleași înregistrări ale operațiilor. Ultima încercare și implementarea verificată curentă sunt afișate separat, iar o sarcină AI încheiată nu înseamnă o implementare reușită.

  4. sondă HTTPS publicăgitops/bridge.pyHTTPS healthURL HTTPS public

    Verifică doar adresa HTTPS de health înregistrată de operator, fără redirecționări, pentru 200 (și JSON-ul așteptat, dacă este setat).

Fiecare conexiune cu aceeași grosime. Alegeți un flux pentru a evidenția doar traseul lui, cu pași numerotați.

  • Continuă · direcția în care circulă sursa, imaginile și cererile
  • Întreruptă · cerere de rulare, aplicare sau sincronizare
  • Linie-punct lungă · citiri de stare, sonde și metrici, separate de verdict
  • Liniuță scurtă · un eșec înregistrat sau un rezultat necunoscut
  • Linie neagră groasă · fluxul selectat; numerele dau ordinea
  • Casetă · o graniță cu proprietar, cu calea sursei în antet
  • Etichetă interioară · o componentă din acea graniță
  • Casetă întreruptă · în afara platformei
  • Contur portocaliu · locul în care decide un model
  • API-ul produsului
  • Înregistrările implementărilor
  • Granița de execuție CD
  • Intrare · CI · țintă

Imaginea din 2 octombrie (bc61a5a) din docs/architecture/README.md este istoric de implementare; această arhitectură urmează codul 645e28a. Furnizorii și căile de rețea diferă în funcție de ținta înregistrată, iar asta nu înseamnă că fiecare furnizor este mereu activ.