Dependency Stability and AI Dependency Watch Plan

Purpose

This note captures the dependency-hardening approach for the DataInsideData™ platform.

The goal is not to remove every dependency. Modern projects depend on frameworks, packages, APIs, scripts, and build tools. The real goal is to make dependencies controlled, pinned, reproducible, reviewable, and intentionally updated.

Core Principle

same code + same dependency versions + same build process = repeatable result

If dependencies float without version control, a project can break later even if the project code did not change.

Dependency Layers in This Project

The platform currently has several dependency layers:

  • Ruby / Jekyll dependencies
  • Python workflow scripts
  • JavaScript browser libraries
  • Deno / Supabase Edge Function imports
  • Supabase CLI tooling
  • GitHub Actions / deployment tooling
  • CDN-loaded security/rendering libraries such as Marked and DOMPurify

Each layer should have a stability strategy.

Current Hardening Direction

Ruby / Jekyll

Keep and commit:

Gemfile
Gemfile.lock

Use:

bundle exec jekyll serve
bundle exec jekyll build

Gemfile.lock records the exact working gem versions.

Python

Use a committed dependency file such as:

requirements.txt
environment.yml
pyproject.toml

For now, a pinned requirements.txt or environment.yml is enough.

JavaScript README Renderer

The README renderer is security-sensitive because it handles user-submitted README content.

Current dependencies to control:

marked
DOMPurify

Better:

<script src="https://cdn.jsdelivr.net/npm/marked@EXACT_VERSION/marked.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/dompurify@EXACT_VERSION/dist/purify.min.js"></script>

Best later:

assets/vendor/marked/marked.min.js
assets/vendor/dompurify/purify.min.js

Vendoring these files locally prevents unexpected CDN/package changes from affecting rendering.

Deno / Supabase Edge Function

Keep and commit:

deno.lock

Pin imports more tightly when stability matters.

Example direction:

import { createClient } from "npm:@supabase/supabase-js@2.49.1";

Instead of only relying on a broad major version such as @2.

Supabase CLI

Document the tested CLI version used for deployment.

Example direction:

npx supabase@TESTED_VERSION functions deploy submit-builder-project

GitHub Actions

Use stable action versions and avoid unnecessary floating behavior. For critical workflows, consider pinning more tightly later.

Dependency Dictionary Idea

Create a project dependency dictionary that records important dependencies and why they matter.

Example structure:

dependencies:
  ruby:
    - name: jekyll
      source_file: Gemfile.lock
      purpose: Static site build
      risk_level: medium

  python:
    - name: sqlalchemy
      source_file: requirements.txt
      purpose: Supabase/Postgres workflow scripts
      risk_level: medium

  browser:
    - name: marked
      source_file: _includes/github-project.html
      purpose: Convert README Markdown to HTML
      risk_level: high
      notes: Security-sensitive because it processes user-submitted README content.

    - name: dompurify
      source_file: _includes/github-project.html
      purpose: Sanitize rendered README HTML
      risk_level: high
      notes: Security-sensitive. Must be pinned and tested.

  deno:
    - name: supabase-js
      source_file: supabase/functions/submit-builder-project/index.ts
      purpose: Edge Function database client
      risk_level: high

Eventual AI Dependency Watch Program

Yes, this is doable.

The future program can:

  1. Read a dependency dictionary.
  2. Parse lock files and important source files.
  3. Detect dependency names and current pinned versions.
  4. Check whether newer versions exist.
  5. Compare current version against latest known version.
  6. Flag major/minor/security-sensitive changes.
  7. Generate a human-readable dependency report.
  8. Optionally ask an AI model to summarize risk and recommended action.

Possible Program Inputs

Gemfile.lock
requirements.txt
environment.yml
deno.lock
package-lock.json
GitHub Actions workflow files
dependency_watch.yml
_includes/github-project.html
_includes/github-readme.html

Possible Program Output

reports/dependency_watch_report.md

Example report sections:

Dependency Watch Report
- Date generated
- Dependencies scanned
- Current pinned versions
- Available newer versions
- Security-sensitive dependencies
- Suggested review priority
- Human summary
- Recommended next actions

AI Summary Example

The AI layer should not automatically update dependencies.

It should produce review guidance such as:

DOMPurify is security-sensitive because it sanitizes user-submitted README HTML.
A new version exists. Review the changelog, test iframe/script stripping, then update only after local and staging tests pass.

AI recommends.
Humans approve.
Tests confirm.
Then updates are merged.

Future Workflow

dependency_watch.yml
    ↓
dependency scanner script
    ↓
version comparison
    ↓
AI-generated report
    ↓
manual review
    ↓
test branch
    ↓
local + staging build
    ↓
merge if safe

Near-Term Checklist

  • Commit Gemfile.lock
  • Commit deno.lock
  • Create or update requirements.txt / environment.yml
  • Pin Marked and DOMPurify versions
  • Consider vendoring Marked and DOMPurify locally
  • Create dependency_watch.yml
  • Build a first scripts/dependency_watch.py
  • Generate reports/dependency_watch_report.md
  • Add AI summary later after the scanner works

Final Note

Dependency hardening is not about fear of dependencies.

It is about making the platform reproducible, reviewable, and stable enough to grow.