outline: agent-based IDE scope, logo cover, full prioritised roadmap
This commit is contained in:
parent
ff5e010f10
commit
7b460a207d
|
|
@ -10,6 +10,11 @@
|
||||||
<body>
|
<body>
|
||||||
<div class="page">
|
<div class="page">
|
||||||
|
|
||||||
|
<div style="width:100%;height:260px;overflow:hidden;background:#000;margin-bottom:2rem;border-radius:8px;">
|
||||||
|
<img src="../../src/rojos/rojects.svg" alt="Rojects"
|
||||||
|
style="width:100%;height:100%;object-fit:cover;object-position:center;">
|
||||||
|
</div>
|
||||||
|
|
||||||
<header>
|
<header>
|
||||||
<p class="date">Project Documentation</p>
|
<p class="date">Project Documentation</p>
|
||||||
<h1 style="font-size: 300%;">Roject</h1>
|
<h1 style="font-size: 300%;">Roject</h1>
|
||||||
|
|
@ -22,10 +27,14 @@
|
||||||
<div class="card">
|
<div class="card">
|
||||||
<h3>What it is</h3>
|
<h3>What it is</h3>
|
||||||
<p>
|
<p>
|
||||||
Roject is a self-hosted, browser-based CMS for creating, editing, and storing
|
Roject is a self-hosted, agent-based IDE for working with files and projects.
|
||||||
HTML documents with assets, organised into projects. It is designed for individual
|
It provides specialised editors for different file types — a WYSIWYG HTML editor,
|
||||||
developers or small teams who want a lightweight authoring environment with no
|
a CodeMirror-backed code editor, and more editors to come — all within a
|
||||||
external database dependency.
|
multi-panel, tab-based workspace. Projects can be hosted on the Roject server
|
||||||
|
(remote) or opened directly from the local filesystem (local), making it usable
|
||||||
|
both as a lightweight self-hosted CMS and as a full desktop development environment.
|
||||||
|
It is designed for individual developers or small teams and has no external database
|
||||||
|
dependency.
|
||||||
</p>
|
</p>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
@ -66,18 +75,165 @@
|
||||||
|
|
||||||
<div class="card">
|
<div class="card">
|
||||||
<h3>What still needs work</h3>
|
<h3>What still needs work</h3>
|
||||||
<p>
|
<p>Items below are ordered by priority. Major planned features first, then smaller open improvements.</p>
|
||||||
This is a loose reminder, not a fixed backlog. Things we know are missing or
|
|
||||||
incomplete: the Right panel has no default content and relies on manual tab
|
|
||||||
dragging to populate; portrait mode's secondary section switcher
|
|
||||||
(when a panel has multiple side-by-side sections) is not yet wired up; the
|
|
||||||
member list UI shows raw UUIDs instead of usernames; the group editor and
|
|
||||||
account delete button still use the browser <code>confirm()</code> instead of
|
|
||||||
the custom dialog; non-text files (images, PDFs) in the tree are visible but
|
|
||||||
not openable (a <code>MediaViewerPanel</code> is planned); and there is no
|
|
||||||
real-time multi-user collaboration yet.
|
|
||||||
</p>
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
<div class="card">
|
||||||
|
<h3>1 — Production server + CI</h3>
|
||||||
|
<p>
|
||||||
|
Deploy the Node.js/Express app to a publicly reachable server and wire up a
|
||||||
|
CI pipeline that builds, tests, and deploys automatically on push. The app's
|
||||||
|
file-based storage and no-database design make it straightforward to host on
|
||||||
|
any VPS: nginx as reverse proxy, PM2 or a systemd service for the Node.js
|
||||||
|
process. CI can run as a self-hosted Gitea/Forgejo Actions runner (matching
|
||||||
|
the existing self-hosted git remote) or mirror to GitHub Actions. This is
|
||||||
|
infrastructure work rather than feature work — it should be done once and early
|
||||||
|
because everything else ships faster and more safely once a real deployment
|
||||||
|
target and regression-catching pipeline exist.
|
||||||
|
</p>
|
||||||
|
<div class="tags">
|
||||||
|
<span class="tag">nginx</span>
|
||||||
|
<span class="tag">PM2 / systemd</span>
|
||||||
|
<span class="tag">Gitea Actions</span>
|
||||||
|
<span class="tag">VPS</span>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<div class="card">
|
||||||
|
<h3>2 — Electron desktop app + local filesystem access</h3>
|
||||||
|
<p>
|
||||||
|
Package Roject as a standalone desktop application using Electron. Since the
|
||||||
|
frontend is already plain HTML/JS/CSS, the Electron integration is mostly
|
||||||
|
structural: the Express server runs as a child process inside Electron's main
|
||||||
|
process, and the BrowserWindow is pointed at it. No frontend changes are needed
|
||||||
|
to make the existing UI run inside Electron.
|
||||||
|
</p>
|
||||||
|
<p style="margin-top:0.75rem">
|
||||||
|
Local filesystem access follows from this almost for free: the file tree is
|
||||||
|
extended to browse arbitrary directories on the host machine using Node.js
|
||||||
|
<code>fs</code> directly, rather than being restricted to the
|
||||||
|
<code>storage/<uuid>/root/</code> paths managed by the server. This is
|
||||||
|
what turns Roject from a hosted CMS into something closer to VS Code — the
|
||||||
|
user can open any folder on their machine as a project.
|
||||||
|
</p>
|
||||||
|
<p style="margin-top:0.75rem">
|
||||||
|
These two features are treated as a single unit of work: there is no point
|
||||||
|
shipping Electron without local filesystem access, and local filesystem access
|
||||||
|
in the browser would require the File System Access API with significant UX
|
||||||
|
friction. Electron is the cleaner path.
|
||||||
|
</p>
|
||||||
|
<div class="tags">
|
||||||
|
<span class="tag">Electron</span>
|
||||||
|
<span class="tag">child_process</span>
|
||||||
|
<span class="tag">Node.js fs</span>
|
||||||
|
<span class="tag">BrowserWindow</span>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<div class="card">
|
||||||
|
<h3>3 — Local git repository integration</h3>
|
||||||
|
<p>
|
||||||
|
Git integration inside the editor: file status indicators in the tree, staging,
|
||||||
|
commit, push and pull, and eventually diffs and history. This depends on local
|
||||||
|
filesystem access (feature 2) and follows naturally from it — once Roject can
|
||||||
|
open an arbitrary local directory, the git repo that directory belongs to is
|
||||||
|
already there.
|
||||||
|
</p>
|
||||||
|
<p style="margin-top:0.75rem">
|
||||||
|
The implementation uses <code>simple-git</code>, a thin Node.js wrapper around
|
||||||
|
the git CLI, which keeps the dependency surface small and relies on the user's
|
||||||
|
existing git installation. An alternative is <code>isomorphic-git</code> (pure
|
||||||
|
JS, works in the browser too), but the CLI wrapper is simpler for a first
|
||||||
|
iteration. A new panel in the editor displays repo status and exposes the
|
||||||
|
common operations.
|
||||||
|
</p>
|
||||||
|
<div class="tags">
|
||||||
|
<span class="tag">simple-git</span>
|
||||||
|
<span class="tag">git CLI</span>
|
||||||
|
<span class="tag">new panel</span>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<div class="card">
|
||||||
|
<h3>4 — Internet tunnel / port pass-through relay</h3>
|
||||||
|
<p>
|
||||||
|
A tunneling feature that allows local devices — a main workstation running
|
||||||
|
Stable Diffusion, a local LLM, a GDScript language server, or any other
|
||||||
|
service — to be accessible to authorised Roject users over the internet,
|
||||||
|
routed through the Roject server.
|
||||||
|
</p>
|
||||||
|
<p style="margin-top:0.75rem">
|
||||||
|
The architecture: a small local agent (a Node.js script, or a built-in Roject
|
||||||
|
feature) connects to the Roject server via a persistent WebSocket, identifying
|
||||||
|
itself with a secret key. The server maps that key to a Roject user and
|
||||||
|
permission record. When an authorised Roject user (e.g. on their phone) makes
|
||||||
|
a request to the relay endpoint, the server forwards it through the WebSocket
|
||||||
|
to the local agent, which proxies it to the configured local port, and returns
|
||||||
|
the response the same way.
|
||||||
|
</p>
|
||||||
|
<p style="margin-top:0.75rem">
|
||||||
|
The primary use case is mobile-to-desktop: use a phone as a thin client while
|
||||||
|
the main machine handles all heavy processing (image generation, inference,
|
||||||
|
language server completions). The secret key is the only credential needed —
|
||||||
|
it is registered once in Roject's user system and then shared with the local
|
||||||
|
agent. A single pass-through maps one local port to one authorised user.
|
||||||
|
</p>
|
||||||
|
<p style="margin-top:0.75rem">
|
||||||
|
This feature is architecturally independent of Electron and mobile and lives
|
||||||
|
entirely on the server, so it can be developed in parallel with the desktop
|
||||||
|
work. It is placed here because its primary value is unlocked only once mobile
|
||||||
|
access (feature 5) also exists.
|
||||||
|
</p>
|
||||||
|
<div class="tags">
|
||||||
|
<span class="tag">WebSocket relay</span>
|
||||||
|
<span class="tag">HTTP proxy</span>
|
||||||
|
<span class="tag">secret key / auth</span>
|
||||||
|
<span class="tag">local agent</span>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<div class="card">
|
||||||
|
<h3>5 — Mobile app (PWA first, native shell later)</h3>
|
||||||
|
<p>
|
||||||
|
Make Roject usable on a phone or tablet. The quickest path given the existing
|
||||||
|
web frontend is a Progressive Web App (PWA) — a manifest file and a service
|
||||||
|
worker. This costs almost nothing to add, works in Safari and Chrome on both
|
||||||
|
Android and iOS without an app store, and covers the core use case of reaching
|
||||||
|
the editor and the tunnel relay from a mobile browser.
|
||||||
|
</p>
|
||||||
|
<p style="margin-top:0.75rem">
|
||||||
|
If native capabilities are later needed (background processing, push
|
||||||
|
notifications, deeper OS integration), Capacitor can wrap the same web app
|
||||||
|
in a native shell without requiring a framework rewrite. A full React Native
|
||||||
|
or Flutter rewrite would be a significant departure from the existing Web
|
||||||
|
Components architecture and is not planned.
|
||||||
|
</p>
|
||||||
|
<p style="margin-top:0.75rem">
|
||||||
|
The main challenge of a mobile editing experience is the code editor — CodeMirror
|
||||||
|
on a touchscreen is not great for authoring. The realistic mobile workflow is
|
||||||
|
lighter interaction: browsing files, reading output, triggering generation
|
||||||
|
requests through the tunnel relay, and simple edits rather than heavy coding.
|
||||||
|
</p>
|
||||||
|
<div class="tags">
|
||||||
|
<span class="tag">PWA</span>
|
||||||
|
<span class="tag">manifest + service worker</span>
|
||||||
|
<span class="tag">Capacitor (later)</span>
|
||||||
|
<span class="tag">no React Native</span>
|
||||||
|
</div>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<div class="card">
|
||||||
|
<h3>Smaller open improvements</h3>
|
||||||
|
<ul style="line-height:1.9">
|
||||||
|
<li>The Right panel has no default content and relies on manual tab dragging to populate.</li>
|
||||||
|
<li>Portrait mode's secondary section switcher (when a panel has multiple side-by-side sections) is not yet wired up.</li>
|
||||||
|
<li>The member list UI shows raw UUIDs instead of usernames.</li>
|
||||||
|
<li>The group editor and account delete button still use the browser <code>confirm()</code> instead of the custom <code><confirm-dialog></code>.</li>
|
||||||
|
<li>Non-text files (images, PDFs) are visible in the tree but not openable — a <code>MediaViewerPanel</code> is planned.</li>
|
||||||
|
<li>No real-time multi-user collaboration yet.</li>
|
||||||
|
</ul>
|
||||||
|
</div>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section>
|
<section>
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue