WAIT — Stale — last commit 3y ago

• 11 active contributors
• AGPL-3.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 3y ago
• ⚠ Concentrated ownership — top contributor handles 63% of recent commits
• ⚠ AGPL-3.0 is copyleft — check downstream compatibility
• ⚠ Scorecard: marked unmaintained (0/10)
• ⚠ Scorecard: default branch unprotected (0/10)

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests + OpenSSF Scorecard}

Grid Studio is a web-based spreadsheet application written in Go that integrates Python, JavaScript, and shell commands directly into cells, enabling data science workflows with live execution. It solves the problem of context-switching between spreadsheets and scripts by unifying data manipulation, visualization, and command execution in a single browser-based environment. Two-tier architecture: grid-app/proxy/ contains the centralized workspace manager (manager.go, sessionmanager/) with static dashboard UI (HTML/CSS/jQuery), while grid-app/ itself is the per-workspace Go runtime with cell parsing (parse.go), Python integration (python.go), Node.js terminal (client.go), and WebSocket proxy (websocketproxy/). State is managed via SQLite databases in proxy/db/.

Data scientists and analysts who want spreadsheet familiarity (standard functions like SUM, FILTER) combined with Python scripting power without leaving the UI; developers building data processing pipelines who need a literate computing environment with shell access.

Actively developed but not yet 1.0: the repository has a Docker-based installation flow, CI/CD via GitHub Actions (.github/workflows/ci.yml), and substantial codebases in Go (172KB) and JavaScript (653KB), but limited test suite visibility suggests it's post-alpha/pre-production. The project has clear documentation wiki references and CONTRIBUTORS.md, indicating ongoing maintenance.

Single-maintainer repository (ricklamers/) with no visible test directory in file listing; Python integration via grid-app/python/ appears minimal (8.9KB Python) and may have security implications for untrusted workspaces. Docker dependency means offline/air-gapped deployments require pre-built images, and workspace isolation relies on Go's process management without obvious sandboxing.

No recent commit data visible in file list, but the codebase structure suggests active work on Python integration (python.go, python/pycache), session management (sessionmanager/sessionmanager.go), and WebSocket-based cell evaluation. The presence of build.log and build.sh indicates ongoing containerization efforts.

git clone https://github.com/ricklamers/gridstudio.git && cd gridstudio && docker build -f grid-app/Dockerfile -t gridstudio . && docker run -p 8080:8080 gridstudio (see README and wiki/Installation for detailed setup).

Daily commands: No traditional npm/yarn dev server; instead: (1) ensure Go 1.x and Python 3.x installed, (2) run grid-app/grid.go or use Docker: docker build -f grid-app/Dockerfile -t gs . && docker run -it gs. The proxy component runs via grid-app/proxy/run-manager-proxy.sh. Frontend is served as static assets from grid-app/static/ and proxy/static/dashboard/.

• grid-app/main.go — Entry point for the entire Grid Studio application; initializes the web server and orchestrates workspace management and execution.
• grid-app/grid.go — Core spreadsheet cell parser and evaluator; implements the grid computation engine that processes formulas and integrates with Python.
• grid-app/hub.go — WebSocket hub managing real-time client connections and broadcasting cell updates across active sessions.
• grid-app/proxy/manager.go — Workspace manager CRUD interface and routing; handles workspace lifecycle and proxies traffic to individual execution environments.
• grid-app/python.go — Python interpreter integration layer; bridges spreadsheet cells to Python runtime for data manipulation and analysis.
• grid-app/detector/detector.go — Language and cell-type detection; determines whether a cell contains Python code, formulas, or raw data.
• grid-app/proxy/websocketproxy/websocketproxy.go — WebSocket proxy between workspace manager and execution environments; enables real-time communication for distributed sessions.

• Grid Engine (grid.go, parse.go) (Go) — Parses cell formulas and expressions; evaluates references; delegates Python code to runtime; maintains grid state.
  • Failure mode: Parsing error or infinite loop in formula → cell fails silently or hangs; no automatic recovery.
• Python Bridge (python.go) (Python, subprocess, Go runtime/cgo) — Executes user code in subprocess; captures stdout/stderr; maintains Python context (variables, imports) per session.
  • Failure mode: Python error or timeout → cell shows error message; exception does not propagate to Go; timeout terminates subprocess.

Add a new spreadsheet function

1. Define the function signature and logic in the grid evaluation engine (grid-app/grid.go)
2. Add parsing rules to recognize the function syntax (grid-app/parse.go)
3. If the function requires Python, add execution logic in the Python bridge (grid-app/python.go)
4. Test by creating a cell that references the new function and trigger evaluation via WebSocket

Add Python integration for a new data science library

1. Import and initialize the library in the Python setup module (grid-app/python/init.py)
2. Expose library functions through the Python bridge to cells (grid-app/python.go)
3. Test by writing Python code in a grid cell that uses the new library

Add a new workspace manager endpoint

1. Define the HTTP handler in the workspace manager (grid-app/proxy/manager.go)
2. Wire the route in main.go or relevant routing configuration (grid-app/main.go)
3. If persistent, add database logic to sessionmanager (grid-app/proxy/sessionmanager/sessionmanager.go)
4. Add client-side action in the dashboard JavaScript (grid-app/proxy/static/dashboard/js/actions.js)

Add a new UI dashboard feature

1. Add HTML markup to the dashboard template (grid-app/proxy/static/dashboard/index.html)
2. Add styling rules to the dashboard stylesheet (grid-app/proxy/static/dashboard/css/style.css)
3. Add event handlers and logic to the actions module (grid-app/proxy/static/dashboard/js/actions.js)
4. Implement corresponding backend endpoint in the manager if data persistence is needed (grid-app/proxy/manager.go)

• Go (Backend) — High-performance server for handling concurrent WebSocket connections, fast cell parsing/evaluation, and efficient memory management for grid data.
• Python (Data Science) — Deep integration with popular data science libraries (pandas, numpy, scikit-learn) enables seamless data manipulation directly within spreadsheet cells.
• WebSockets (Real-time Sync) — Bi-directional communication allows instant propagation of cell updates across all connected clients without polling overhead.
• Docker (Deployment) — Containerization ensures reproducible environments with Python and all dependencies bundled, simplifying deployment and scaling.
• JavaScript/HTML/CSS (Frontend) — Web-based UI provides cross-platform accessibility and integrates easily with dashboard management and session controls.

• Python subprocess execution vs. embedded interpreter

  • Why: Subprocess isolation prevents Python errors from crashing the main Go process and allows sandboxing/resource limits.
  • Consequence: Added latency (~100-200ms per cell execution) and inter-process communication overhead; limits shared state across cells without explicit context passing.

• Centralized workspace manager + distributed execution environments

  • Why: Separates session management and user data from computational load; enables horizontal scaling of execution pods.
  • Consequence: Added network hop via proxy layer; increased complexity for distributed state synchronization and potential single point of failure in manager.

• In-memory grid state (no automatic persistence layer shown)

  • Why: Simplifies architecture and provides fast cell access; workspace manager stores sessions but not real-time grid snapshots.
  • Consequence: Risk of data loss on server restart unless explicitly saved to disk; manual save/load required for persistence.

• WebSocket hub broadcasts to all clients vs. selective updates

  • Why: Simpler implementation ensures all clients stay perfectly in sync.
  • Consequence: May send redundant updates to clients; does not scale efficiently for large teams (O(n) broadcast cost).

• Real-time collaborative editing with conflict resolution (no OT/CRDT implementation evident)
• Persistent data warehouse or time-series storage for historical cell versions
• Authentication/authorization and multi-tenant isolation (proxy manager is minimal on auth)
• Horizontal scaling across multiple machines without custom orchestration
• Native mobile client support

Python execution happens in-process without apparent sandboxing (grid-app/python.go) — untrusted user code can access the host filesystem. WebSocket proxying assumes authenticated sessions (sessionmanager/) but authentication mechanism not visible in file list. Cell evaluation is synchronous in parse.go, risking UI hangs on slow Python code. Database migrations not visible; schema changes may break existing workspaces. Node.js terminal (client.go) runs arbitrary shell commands without visible privilege restrictions.

• Cell dependency graph resolution — Spreadsheets require topological sorting to execute cells in correct order; Grid Studio's parse.go likely implements this to handle formulas referencing other cells
• WebSocket bidirectional sync — grid-app/hub.go and websocketproxy/ implement real-time cell updates; understanding frame buffering and backpressure is critical for scaling to large grids
• Process isolation and IPC (Inter-Process Communication) — Python and Node.js runtimes run as child processes; Grid Studio must serialize data in/out via pipes or sockets (see python.go and client.go)
• Lazy evaluation and memoization — Spreadsheets cache cell values to avoid recomputation; Grid Studio likely implements memoization in hub.go to prevent redundant Python execution
• Session management and state persistence — proxy/sessionmanager/ and proxy/db/ must track user sessions and workspace state; SQLite is used to persist grids across container restarts
• Reverse proxy and request routing — grid-app/proxy/manager.go routes requests to per-workspace instances; critical for multi-tenancy and workspace isolation
• Formula tokenization and AST generation — parse.go must convert text like '=SUM(A1:A10)' into an abstract syntax tree for evaluation; affects both correctness and performance

• pydata/pandas — Grid Studio's Python data manipulation is primarily through pandas; many cells will use pd.read_csv(), df.groupby(), etc.
• jupyter/notebook — Closest competitor in literate computing space; Grid Studio differentiates by using spreadsheet UI instead of cell-based notebooks
• plotly/plotly.js — Likely visualization library for Grid Studio data outputs; frontend integrates charting capabilities
• tornadoweb/tornado — Python async web framework often used with data science dashboards; potential upgrade path for Grid Studio's Python backend
• microsoft/vscode — VS Code's integrated terminal and Jupyter extension represent adjacent UI patterns for code execution in a workspace

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for grid-app/parse.go cell parsing logic

The parse.go file handles critical cell parsing and evaluation for the spreadsheet backend, but there's no evidence of dedicated tests in the repo structure. This is foundational logic that needs test coverage to prevent regressions. Tests would validate formula parsing, cell references, and expression evaluation across Python/Go integration.

• [ ] Create grid-app/parse_test.go with test cases for cell expression parsing
• [ ] Add tests for Python expression evaluation and Go expression handling
• [ ] Add tests for cell reference resolution and circular dependency detection
• [ ] Run tests via 'go test ./...' and integrate into .github/workflows/ci.yml

Add CI workflow for Go application build and test

The .github/workflows/ci.yml exists but appears to lack Go-specific testing. The grid-app/ backend is written in Go (main.go, grid.go, hub.go, etc.) but there's no evidence of automated Go compilation, linting, or unit test execution in the CI pipeline. This is critical for a production web application.

• [ ] Review existing .github/workflows/ci.yml and add Go build step using actions/setup-go
• [ ] Add 'go build ./...' for grid-app/ directory to catch compilation errors
• [ ] Add 'go test ./...' with coverage reporting for grid-app/
• [ ] Add golangci-lint or similar linting action to catch style issues
• [ ] Ensure workflow runs on push and PR to main branch

Add integration tests for Python-Go bridge in grid-app/python.go

The python.go file is the critical bridge between the Go spreadsheet backend and Python runtime, but there's no test evidence. Given the examples/ directory contains sample Python scripts (estimate_normal.py, scrape.py), integration tests should verify that Python code execution, variable passing, and result marshaling work correctly.

• [ ] Create grid-app/python_test.go with tests for Python script execution
• [ ] Add test cases that execute grid-app/examples/* scripts and validate output
• [ ] Test variable passing between Go cells and Python runtime
• [ ] Test error handling when Python code fails or times out
• [ ] Add tests for data type conversion between Python and Go/spreadsheet types

• Add unit tests for grid-app/parse.go expression parser — currently no test files visible for critical formula parsing logic; start with SUM() and FILTER() function parsing: Formula parsing is core to correctness and risks silent bugs; tests would catch regression on formula changes
• Document the Python integration layer (grid-app/python.go and grid-app/python/init.py) with inline examples showing how to call Python from cells — currently minimal code comments: This is a key differentiator vs. Excel but is underdocumented; examples would unlock adoption
• Add TypeScript types for the WebSocket message protocol between proxy/websocketproxy/ and frontend grid-app/proxy/static/dashboard/js/actions.js — currently raw JavaScript: Prevents client/server message format desync bugs; TypeScript types would catch integration issues early

• High · Outdated Webpack Dependencies — package.json - devDependencies. The project uses webpack 4.5.0 and webpack-cli 2.0.14, which are significantly outdated (released in 2018). These versions contain known security vulnerabilities including potential arbitrary code execution and prototype pollution issues. Fix: Update webpack to version 5.x or higher and webpack-cli to version 4.x or higher. Run 'npm audit' to identify and fix all vulnerable dependencies.
• High · Missing Input Validation in Go Backend — grid-app/parse.go, grid-app/grid.go. The file structure indicates Go cell parsing and evaluation (grid.go, parse.go) without visible input sanitization mechanisms. Cell expressions could be vulnerable to injection attacks if user input is directly evaluated without proper validation. Fix: Implement strict input validation and sanitization for all cell expressions. Use a sandboxed environment for cell evaluation. Avoid direct code execution of user input.
• High · Python Runtime Integration Risk — grid-app/python.go, grid-app/python/init.py. The application integrates Python runtime for cell manipulation (python.go, python/init.py). Without proper sandboxing, users could execute arbitrary Python code that accesses the file system, network, or system resources. Fix: Implement Python code sandboxing using containers, restricted namespaces, or a dedicated sandboxing library. Restrict available Python modules and system calls. Use RestrictedPython or similar libraries for safer code execution.
• High · WebSocket Proxy Without Apparent Rate Limiting — grid-app/proxy/websocketproxy/websocketproxy.go. The WebSocket proxy implementation (websocketproxy/websocketproxy.go) lacks visible rate limiting or DDoS protection mechanisms, making the application vulnerable to resource exhaustion attacks. Fix: Implement rate limiting, connection throttling, and DDoS protection mechanisms. Add maximum message size limits and connection timeouts.
• Medium · SQLite Database in Repository — grid-app/proxy/db/manager.db, grid-app/proxy/db/manager-empty.db. SQLite database files are present in the repository (proxy/db/manager.db, manager-empty.db). These files could contain sensitive data and their presence in version control is a security anti-pattern. Fix: Remove database files from version control. Add to .gitignore. Store production databases outside the codebase. Use environment-based database configuration.
• Medium · Session Management Without Visible Security Controls — grid-app/proxy/sessionmanager/sessionmanager.go, grid-app/proxy/logs/sessionlogs. Session manager implementation (sessionmanager/sessionmanager.go) lacks visible session tokens, CSRF protection, or secure session storage mechanisms. Session logs are stored in plaintext directories. Fix: Implement secure session tokens with cryptographic generation. Add CSRF protection using token-based verification. Encrypt sensitive session data at rest. Implement proper session expiration.
• Medium · User Data Directory Without Access Control Visibility — grid-app/proxy/userdata. User data is stored in plaintext directories (proxy/userdata) without clear access control mechanisms. File permissions and data isolation between users are not evident. Fix: Implement user-based access controls and data isolation. Encrypt sensitive user data at rest. Implement proper file permission management. Audit data access patterns.
• Medium · Missing Security Headers in Static Files — grid-app/proxy/manager.go (likely), grid-app/proxy/static/. Static files are served (static/, proxy/static/) without visible Content-Security-Policy, X-Frame-Options, or other security headers configured in the proxy. Fix: Configure security headers: X-Frame-Options, X-Content-Type-Options, Content-Security-Policy, Strict-Transport-Security. Implement in the Go proxy manager.
• Medium · Proxy Manager Without Visible Authentication — grid-app/proxy/manager.go, grid-. The proxy manager (proxy/manager.go) lacks visible authentication mechanisms. The login.html suggests authentication exists, but implementation is not evident. Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/ricklamers/gridstudio shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live ricklamers/gridstudio repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ricklamers/gridstudio.

What it runs against: a local clone of ricklamers/gridstudio — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in ricklamers/gridstudio | Confirms the artifact applies here, not a fork | | 2 | License is still AGPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 945 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of ricklamers/gridstudio. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/ricklamers/gridstudio.git
#   cd gridstudio
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of ricklamers/gridstudio and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ricklamers/gridstudio(\\.git)?\\b" \\
  && ok "origin remote is ricklamers/gridstudio" \\
  || miss "origin remote is not ricklamers/gridstudio (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(AGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"AGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is AGPL-3.0" \\
  || miss "license drift — was AGPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "grid-app/main.go" \\
  && ok "grid-app/main.go" \\
  || miss "missing critical file: grid-app/main.go"
test -f "grid-app/grid.go" \\
  && ok "grid-app/grid.go" \\
  || miss "missing critical file: grid-app/grid.go"
test -f "grid-app/hub.go" \\
  && ok "grid-app/hub.go" \\
  || miss "missing critical file: grid-app/hub.go"
test -f "grid-app/proxy/manager.go" \\
  && ok "grid-app/proxy/manager.go" \\
  || miss "missing critical file: grid-app/proxy/manager.go"
test -f "grid-app/python.go" \\
  && ok "grid-app/python.go" \\
  || miss "missing critical file: grid-app/python.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 945 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~915d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/ricklamers/gridstudio"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.