diff --git a/package.json b/package.json index 319938d..b479aa8 100644 --- a/package.json +++ b/package.json @@ -45,7 +45,7 @@ }, "scripts": { "start": "react-scripts start", - "prebuild": "node scripts/generate-sitemap.js", + "prebuild": "node scripts/generate-sitemap.js && node scripts/generate-llms-full.js", "build": "react-scripts build", "postbuild": "node scripts/prerender.js", "test": "react-scripts test", diff --git a/public/Profile/Om_Sherikar.png b/public/Profile/Om_Sherikar.png new file mode 100644 index 0000000..6c9d9b6 Binary files /dev/null and b/public/Profile/Om_Sherikar.png differ diff --git a/public/index.html b/public/index.html index 1dda868..aa07fc0 100644 --- a/public/index.html +++ b/public/index.html @@ -29,9 +29,9 @@ Refactron | Safe, Verified Refactoring + content="Refactron is a deterministic, behavior-preserving refactoring engine for legacy code — no LLM in the loop, verified before every write. Runs locally." /> + content="deterministic refactoring, behavior-preserving refactoring, legacy code modernization, no-LLM code refactoring tool, safe refactoring engine, verified code refactoring, Python refactoring, TypeScript refactoring, technical debt, local-first developer tools" /> @@ -46,7 +46,7 @@ + content="Deterministic, behavior-preserving refactoring engine for legacy code. No LLM in the loop. Verified before every write." /> @@ -54,7 +54,7 @@ + content="Deterministic, behavior-preserving refactoring engine for legacy code. No LLM in the loop. Verified before every write." /> @@ -97,7 +97,7 @@ } - + + + + diff --git a/public/llms-full.txt b/public/llms-full.txt new file mode 100644 index 0000000..b5066b8 --- /dev/null +++ b/public/llms-full.txt @@ -0,0 +1,872 @@ +# Refactron + +> Deterministic, behavior-preserving refactoring engine for legacy code. No LLM in the loop. Every change is verified before it touches disk. Runs entirely locally. + +Refactron is a refactoring tool for production codebases. It analyzes architectural debt (circular imports, duplicated code, deprecated APIs, missing type hints, callback-based async), applies deterministic rule-based transforms, and runs verification gates (syntax / imports / tests / invariants) before any file is rewritten. Rollback is a single command. Same input, same output — that's the moat. + +It is **not** an LLM-based code generator. The engine is rule-based. Refactron does not send code to any external service by default. + +- Languages: Python, TypeScript, JavaScript (today); Go, Rust, Java on the roadmap. +- Install: `pip install refactron` (Python) or `npm install -g refactron` (Node). +- Locality: runs on your machine; telemetry disabled by default. +- Founder: Om Sherikar (Bengaluru, India). Built solo. +- Distribution: 3,500+ PyPI downloads with no paid marketing. +- Recognition: India Ascends — Lightspeed; F6S founder grant. + +## How Refactron works (pipeline) + +1. **Analyze.** Map every import edge. Surface legacy patterns across the full dependency tree without modifying any files. +2. **Refactor.** Apply deterministic transforms. Behavior is mathematically preserved across each transform. +3. **Verify.** Run syntax checks, import validation, and the existing test suite. If any gate fails, the original file is untouched. +4. **Document.** Auto-generate inline docs, changelogs, and function-level summaries after every verified refactor. + +## Safety constraints (the five guarantees) + +1. **Read-only analysis by default.** Refactron scans and reports first. Nothing is written until you explicitly approve a change. +2. **Human-in-the-loop refactoring.** Every change requires explicit developer approval — like a PR review. +3. **Verification to preserve behavior.** Automated checks confirm functional equivalence: syntax, imports, tests, invariants. +4. **Small, incremental changes.** Refactor in scoped, reviewable steps. Never a one-shot rewrite. +5. **Rollback support.** Undo any changeset with a single command. No git required. + +## How Refactron compares + +| Capability | Refactron | Cursor | SonarQube | CodeAnt | +| -------------------------------- | --------- | ------ | --------- | ------- | +| Finds legacy code | yes | no | no | no | +| Refactors it structurally | yes | no | no | no | +| No LLM in the engine | yes | no | yes | no | +| Verifies safety before write | yes | no | no | no | +| Generates docs after refactor | yes | no | no | no | +| Runs fully local | yes | no | no | no | + +Cursor and CodeAnt lean on LLMs (non-deterministic). SonarQube analyzes but does not refactor. Refactron analyzes, refactors deterministically, and verifies before write. + + +## Origin + +At a hackathon, Om Sherikar watched a team avoid an entire part of their codebase. Nobody wanted to risk breaking it. He couldn't find a tool that would actually go in, fix the legacy code, and prove nothing broke. So he built one. + +That's the gap Refactron exists to close. The tools that existed could *find* legacy code or *generate* new code. None of them could actually *refactor* the old code and *prove* it was safe. + + +## Frequently asked questions + +### Does Refactron change my code automatically? + +No. Every structural refactor is shown as a readable diff. Low-risk changes can apply automatically. High-risk changes always ask for approval first. You are always in control. + +### How does Refactron ensure changes are safe? + +Every refactor goes through verification checks to preserve behavior. Changes are incremental, measurable, and fully reversible. + +### Can I use this on production or legacy code? + +Yes. Refactron is designed for long-lived and production codebases where safety, traceability, and control matter most. + +### Is my code sent to external services? + +By default, Refactron runs locally with telemetry disabled. Private and on-prem deployment options are planned for teams with strict security requirements. + +### Which languages are supported? + +Python, TypeScript, and JavaScript are fully supported today. Go, Rust, and Java are on the roadmap. + +### Is this open source? + +The core platform is proprietary. Some tooling and libraries are open for early access and community feedback. + + +## Blog — case studies and deep-dives + +### I Ran Refactron on Django's Codebase. Here's What It Found. + +*Published March 31, 2026 — https://refactron.dev/blog/i-ran-refactron-on-djangos-codebase* + +> 300,000+ lines of Python, 18 years of contributors, used in production by millions. If Refactron is useful on real-world Python code, it should have something to say about Django. Here's what happened. + +One of the best ways to understand what a code analysis tool actually does is to point it at a codebase you didn't write. No bias, no familiarity, no tendency to skip over the parts you know are messy. + +Django is the obvious choice. 300,000+ lines of Python, maintained by hundreds of contributors over nearly two decades, used in production by millions of applications. If Refactron is useful on real-world Python code, it should have something to say about Django. + +Here's what happened. + +## Setup + +\`\`\` +git clone https://github.com/django/django +cd django +pip install refactron +refactron analyze . +\`\`\` + +Analysis runs locally. No code leaves the machine. Took about 40 seconds on a standard MacBook Pro. + +## What it found + +Django is a well-maintained, mature codebase — so the expectation going in was that the obvious stuff would already be handled. That held up. No hardcoded secrets, no SQL injection patterns, no clear security issues in the parts of the codebase that matter most. + +What Refactron did surface was structural complexity — the kind that accumulates in any codebase that's been evolving for 18 years. + +Complexity hotspots. Several functions across the ORM and template engine came back with high cyclomatic complexity scores. These aren't bugs. They're functions that have grown organically to handle a large number of edge cases, and they're hard to read as a result. Django's maintainers know about most of them — they're documented in comments. But seeing them flagged with specific line numbers and complexity scores makes the scope concrete. + +Long parameter lists. A handful of view-related functions have accumulated parameters over multiple release cycles. Again, not broken — just increasingly difficult to call correctly without referring to the docs. The kind of thing that's fine when one person owns the code and becomes a maintenance burden as the team grows. + +Dead code candidates. A small number of internal utilities that appear unreferenced within the codebase. Some of these are intentionally public API — tools or hooks that external projects depend on — which is exactly why Refactron surfaces them as candidates rather than applying automatic fixes. Context matters. The tool flags, you decide. + +## What it didn't do + +It didn't try to rewrite Django's ORM. It didn't suggest architectural changes it couldn't verify. It didn't produce a hundred false positives because it misunderstood a pattern. + +The autofix step — I ran it with --dry-run first, which shows proposed changes without applying them. The suggestions it was confident enough to propose were narrow: unused imports in a few utility modules, a small number of variable naming inconsistencies in non-public code. + +\`\`\` +refactron autofix . --verify --dry-run +\`\`\` + +For the complexity issues it found, it flagged them and stopped. Complex functions that are deeply intertwined with behavior across the codebase are exactly the category where automated fixes without full context are dangerous. Refactron knows this. It surfaces the information and leaves the decision to you. + +## The honest takeaway + +Django is not the right target for aggressive automated refactoring and Refactron didn't pretend otherwise. A codebase this mature, this widely depended on, with this many external consumers needs careful human judgment on anything structural. + +What the analysis is useful for is orientation. If you're a new contributor trying to understand where the complexity lives, or a team using Django's patterns as a reference for your own codebase, the output gives you a map. Here's where the complexity is concentrated. Here's what's worth reading carefully before you touch it. + +For most teams Refactron is aimed at — companies with 2-5 year old Python codebases that have accumulated debt without Django's level of test coverage and contributor scrutiny — the tool has more to say and more it can safely do. But testing against Django was the right first move. If it handles a codebase this large and this well-known without producing noise, it'll handle yours. + +## Try it on your own codebase + +\`\`\` +pip install refactron +refactron analyze . +\`\`\` + +Read-only. Nothing changes. See what's there. + +Next in this series: Flask and Requests — smaller codebases, different patterns, different findings. + +--- + +### Refactron vs Cursor vs CodeAnt: Why "AI Refactoring" Means Three Different Things + +*Published March 31, 2026 — https://refactron.dev/blog/refactron-vs-cursor-vs-codeant* + +> Three tools all claim to do "AI refactoring." They are solving completely different problems. Here is how to tell them apart and which one actually fits your use case. + +If you search for "AI refactoring tool" right now, three names come up repeatedly: Cursor, CodeAnt, and Refactron. All three claim to use AI to improve your code. All three are genuinely useful. And all three are solving completely different problems. + +The confusion is understandable — the marketing overlaps, the feature lists sound similar, and if you are evaluating tools quickly, it is easy to mistake one for another. This post is a direct comparison so you know exactly what you are choosing between. + +## What each tool actually does + +Cursor is a code editor with a deeply integrated AI pair programmer. It helps you write new code faster. You describe what you want, and it generates it inline. You ask about a function, and it explains it. You select a block and say "refactor this," and it rewrites it. Cursor is excellent at this. It is an IDE-level productivity layer for day-to-day coding. + +CodeAnt is a code quality and vulnerability scanner. It runs static analysis across your repository, finds security issues, compliance violations, and code smells, and surfaces them in a dashboard. Think of it as an automated code reviewer that runs on your entire codebase continuously. It is good at cataloging problems and providing a centralized view of code health over time. + +Refactron is a structured refactoring engine for production Python codebases. It identifies maintainability issues — high coupling, duplicated logic, unclear structure — and proposes concrete, behavior-preserving transformations. The distinguishing feature is that every change is verified before it is applied. If a transformation would break a test, the original file is never touched. + +## The question each tool answers + +These three tools answer different questions. + +Cursor answers: "How do I write this code faster?" + +CodeAnt answers: "What quality and security problems exist across my repository?" + +Refactron answers: "Which parts of my codebase need structural improvement, and how do I change them safely?" + +If you are greenfield development or want AI assistance while writing, Cursor is the right tool. If you want continuous visibility into code health and vulnerability exposure, CodeAnt is the right tool. If you have an existing production codebase that has accumulated technical debt and you need a way to reduce it without introducing regressions, that is the Refactron problem. + +## Where the confusion comes from + +The phrase "AI refactoring" has become a catch-all term for anything that uses AI to touch existing code. Cursor can rewrite a selected function. CodeAnt can suggest a fix for a flagged issue. Both of those technically involve changing existing code using AI, so both technically qualify as "AI refactoring." + +The difference is intent and verification. + +Cursor's refactoring is reactive and inline — you select code, you ask it to improve something, it generates a replacement. Whether the replacement preserves behavior is your problem to verify. The tool does not know what the function is supposed to do. + +CodeAnt's suggested fixes are narrow and rule-based — here is a security vulnerability, here is the standard fix pattern. The suggestions are conservative by design because they are derived from static analysis, not deep structural understanding. + +Refactron's refactoring is proactive and verified — it analyzes the codebase structure, identifies transformations that would improve maintainability, generates the change, and then runs syntax checks, import integrity checks, and your test suite against the proposed change before writing anything to disk. If the tests fail, nothing changes. + +## When you would use all three + +These tools are not mutually exclusive. A typical engineering team might use all three: + +- Cursor for daily coding — writing new features, explaining unfamiliar code, generating boilerplate +- CodeAnt for continuous security and compliance monitoring — catching vulnerabilities before they reach production +- Refactron for quarterly or monthly refactoring sprints — improving the structural health of the codebase in a controlled, safe way + +The mistake is treating them as competing alternatives for the same job. They cover different layers of the engineering workflow. + +## The core difference in philosophy + +Cursor and most AI coding tools operate on the assumption that the developer is in the loop at every step. You review what the AI generates before it runs. The speed is worth the occasional mistake. + +Refactron operates on a different assumption: in production codebases, the cost of a subtle regression is high enough that the tool itself must be responsible for verification, not just the developer. The workflow is not "generate and review" — it is "generate, verify against the codebase's own tests, then apply." + +This distinction matters most for older codebases with complex behavior that is not always obvious from reading the code. When you have a codebase that has been running for three years and your engineers are hesitant to touch certain files, the problem is not that they lack an AI assistant. The problem is that they lack a way to make changes with confidence. + +That is the specific problem Refactron was built to solve. + +--- + +### Why We Built a Verification Engine Before an AI Refactoring Engine + +*Published March 31, 2026 — https://refactron.dev/blog/why-we-built-verification-engine-first* + +> Every AI coding tool can find and fix problems. None of them tell you whether the change is safe before applying it. That gap is the entire problem Refactron was built to solve. + +Every AI coding tool launched in the last two years has the same pitch. It finds problems in your code and fixes them. Fast, impressive in demos, and all with the same invisible problem. + +None of them can tell you whether the change is actually safe before they apply it. + +That gap is not minor. That's the entire thing that matters when you're touching a production Python codebase that's been running for years. + +## The problem everyone ignores + +CodeScene analyzed over 100,000 AI-assisted refactoring attempts and found that 63% introduced at least one unintended behavioral change. Not traditional bugs — quiet divergences from what the code was doing before. + +This keeps happening because LLMs are probabilistic. They generate the most likely correct transformation. "Most likely correct" is fine for a lot of tasks. It's not acceptable for production code where correctness is binary — either the behavior is preserved or it isn't. + +The result: developers don't trust automated refactoring on code that matters. They use it for greenfield work and avoid it on anything that's been in production for more than a year. + +## The insight + +Most tools treat verification as a post-processing step. Apply the change, run the tests, see if anything broke, roll back if needed. + +We think this ordering is wrong. + +By the time you're verifying, you've already modified the filesystem. The code is in an unknown state. For teams with CI/CD pipelines that trigger on file changes, that window is enough to kick off a deployment. + +More importantly — verify-after-write doesn't change how developers feel about the tool. The anxiety doesn't go away. It just gets deferred to the test run. + +Verification has to come before the write, not after it. The original file should never be touched until the change is proven safe. + +This is the principle behind Refactron's verification engine. Three checks run against the transformed code before anything is applied. If all three pass, the file is updated. If any fail, the original is untouched — and you see exactly what was blocked and why. + +## What it feels like in practice + +\`\`\` +$ refactron autofix src/api/views.py --verify + + ✔ Syntax check 12ms + ✔ Import integrity 8ms + ✔ Tests passed 6.2s + + Confidence: 97% | Safe to apply. +\`\`\` + +When a change gets blocked: + +\`\`\` +$ refactron autofix src/payments/service.py --verify + + ✔ Syntax check 11ms + ✔ Import integrity 9ms + ✗ Tests FAILED + test_payment_flow::test_refund — assertion error + + Change was NOT applied. Original file untouched. +\`\`\` + +That second output is the product. A change that would have broken a test was caught before it reached the filesystem. No rollback needed. No incident. No 2am page. + +## Why this matters for legacy codebases + +The number one reason teams avoid automated refactoring on legacy code is fear of regressions — not lack of tools. + +A codebase that's been running for three years has accumulated behavior that isn't always documented or tested. Automated tools that write first and verify later amplify that fear because developers know from experience that subtle breaks slip through. + +Verify-before-write addresses the fear at the mechanism level. When the tool can show you proof of safety before touching a file, the mental model shifts from "let's hope this didn't break anything" to "I have evidence this is safe." + +That shift is what makes automated refactoring actually usable on production code. + +## Where we are + +Refactron is live for Python. The verification engine is the core of the product — everything else is built around it. + +\`\`\` +pip install refactron +refactron analyze . +\`\`\` + +Analysis is read-only. It won't change anything. When you're ready: + +\`\`\` +refactron autofix . --verify +\`\`\` + +Everything that passes gets applied. Everything that would break something gets blocked. Your original files are untouched until there's proof of safety. + +--- + +### Improving Maintainability in a Legacy Codebase + +*Published January 15, 2025 — https://refactron.dev/blog/legacy-code-ai-refactoring* + +> Automated refactoring and documentation to modernize legacy codebases, reducing technical debt and regression risks. + +Legacy codebases accumulate complexity over time, making refactoring risky and expensive. Teams often avoid structural improvements due to fear of regressions, missing documentation, and limited test coverage. + +## The challenge + +Long-running codebases build up layers of technical debt that make even small changes feel dangerous. Missing documentation means new engineers reverse-engineer behavior instead of shipping features. Outdated dependencies sit untouched because no one is sure what will break. + +The real problem is not the code itself — it is the absence of tools that can tell you what is safe to change. + +## How Refactron approaches it + +Refactron starts in read-only mode. It analyzes the codebase, identifies maintainability issues, and proposes incremental refactors with preview diffs — so you see exactly what will change before anything does. + +- Surfaces hotspots: long functions, high coupling, duplicated logic +- Proposes behavior-preserving transforms with before/after previews +- Generates documentation tied directly to the code structure +- Flags outdated dependencies and potential security risks +- Every change is reviewable, verifiable, and reversible + +## Results + +Teams using Refactron on legacy codebases report consistently faster refactoring cycles and fewer regressions. The shift from manual, fear-driven refactoring to structured, evidence-backed changes is what makes the difference. + +- 80% reduction in time spent on manual refactoring +- 78 issues detected per analysis on average (5 critical, 20 warnings, 53 informational) +- 2× faster onboarding for new engineers + +Refactron shifts refactoring from ad-hoc manual effort to a structured, safety-first process — making code evolution predictable and easier to trust. + +--- + +### I Ran Refactron on the Requests Library. Here's What It Found. + +*Published February 15, 2026 — https://refactron.dev/blog/refactron-on-requests-library* + +> The Requests library is one of the most downloaded Python packages in existence. Around 15,000 lines of Python — meaning findings are concentrated. Here is what surfaced. + +The Requests library is one of the most downloaded Python packages in existence. Kenneth Reitz released the first version in 2011 with the explicit goal of making HTTP "for humans." Fourteen years later it has over 50,000 GitHub stars, ships inside major cloud SDKs, and gets installed roughly 400 million times a month. + +It's also a relatively small codebase — around 15,000 lines of Python. Which makes it a more interesting test for Refactron than Django. Fewer lines means the findings are more concentrated. If something surfaces here, it's probably worth paying attention to. + +## Setup + +\`\`\` +git clone https://github.com/psf/requests +cd requests +pip install refactron +refactron analyze . +\`\`\` + +Ran in under 8 seconds. Small codebase, fast analysis. + +## What it found + +Complexity in the core session logic. requests/sessions.py is where the most interesting findings landed. The send() method in particular has grown to handle a significant number of conditional paths — redirect handling, adapter resolution, environment proxy logic, certificate verification. Each individual branch makes sense in context. Taken together the function is doing a lot, and the complexity score reflects that. + +This is a well-known pattern in mature HTTP libraries. The session layer has to be the integration point for everything, so it accumulates branches. Not broken, but the kind of function a new contributor will spend real time understanding before feeling confident touching it. + +Unused imports in test files. A handful of imports in the test suite that aren't referenced in the files they live in. Minor, the kind of thing that accumulates over years of test additions and refactors. The autofix step handles these confidently — safe changes with no behavioral implications. + +Long parameter lists in adapter methods. A few internal methods have parameter lists that have grown as new features were added over the years. Again, not broken — but a signal that the API surface has expanded incrementally without a corresponding restructuring pass. + +## The autofix run + +\`\`\` +refactron autofix . --verify --dry-run +\`\`\` + +Dry run first — shows what would change without writing anything. + +For the unused imports in test files, Refactron was confident: clean removals with no downstream references, syntax check passes, import graph unchanged. These would apply safely. + +For the complexity issues, it flagged and stopped. The send() method in sessions touches too many things for automated decomposition to be safe without deeper context about the intended behavior of each path. Refactron surfaces the information. The decision stays with the maintainers. + +This is the right call. Requests is a public API with external consumers who depend on exact behavior. Automated structural changes without exhaustive context would be the wrong move, and the tool knows it. + +## What the output actually looks like + +\`\`\` +✓ Analyzing requests/ + +Files analyzed: 31 +Issues found: 9 + +MEDIUM (4): + High cyclomatic complexity + sessions.py:457 — score: 14 + sessions.py:298 — score: 11 + +LOW (5): + Unused imports + tests/test_utils.py:3 + tests/test_hooks.py:7 + tests/test_structures.py:2 +\`\`\` + +Clean, specific, actionable. No noise. + +## The takeaway + +Requests is a codebase that's been maintained carefully for a long time. The findings Refactron surfaces are the expected residue of organic growth — complexity concentrating in integration points, minor cruft in test files, parameter lists that expanded without a corresponding cleanup pass. + +None of this is alarming. All of it is useful orientation for anyone working in the codebase for the first time, or for a team using Requests as a dependency who wants to understand where the risk lives. + +The more interesting implication is for codebases that haven't been maintained as carefully. If Refactron finds nine issues in one of the most scrutinised small Python libraries in existence, it will find considerably more in a three-year-old internal service that hasn't had a dedicated maintainer since the engineer who wrote it moved on. + +That's the actual target. The open-source runs are a calibration exercise. + +## Try it on yours + +\`\`\` +pip install refactron +refactron analyze . +\`\`\` + +Nothing changes. See what's there. + +Next in this series: FastAPI — modern codebase, different patterns, different findings. + +--- + +### The Real Cost of Not Refactoring Your Python Codebase + +*Published March 5, 2026 — https://refactron.dev/blog/real-cost-of-not-refactoring* + +> Engineering teams talk about technical debt as if it's a known quantity. In practice most teams don't pay it down. They defer it until the codebase becomes something nobody wants to touch. This is not a discipline problem — it's a risk problem. + +Engineering teams talk about technical debt as if it's a known quantity — something you accumulate, acknowledge, and eventually pay down. In practice most teams don't pay it down. They defer it, sprint after sprint, until the codebase becomes something nobody wants to touch. + +This is not a discipline problem. It's a risk problem. Refactoring production code is genuinely dangerous when you don't have a reliable way to verify that the change preserved behavior. So teams make the rational decision: leave it alone. Ship the feature. Deal with the debt later. + +Later never comes. + +## What deferred refactoring actually costs + +The costs are real but they're distributed and slow-moving, which makes them easy to ignore until they're not. + +Velocity loss. A function with cyclomatic complexity 20 takes longer to understand, longer to modify safely, and longer to review than one with complexity 5. Multiply that across hundreds of functions and thousands of developer-hours per year and the number gets uncomfortable quickly. McKinsey estimates that developers spend 23% of their time dealing with technical debt — time not spent on features. + +Regression risk compounds. Tightly coupled, poorly structured code is harder to test. Lower test coverage means higher regression risk. Higher regression risk means more incidents. More incidents mean more time in firefighting mode and less time improving the codebase. The cycle accelerates. + +Onboarding cost. A new engineer joining a team with a clean, well-structured codebase can contribute meaningfully in weeks. The same engineer joining a team with years of accumulated complexity takes months to become productive — and may never fully understand the parts of the system nobody documented because nobody understood them well enough to document. + +The key person risk. Legacy codebases create key person dependencies. The engineer who wrote the payment service three years ago is the only person who truly understands it. When they leave, that knowledge leaves with them. What remains is code that works but that nobody is confident touching. + +## Why teams don't refactor even when they know they should + +The honest answer is fear. Not laziness, not poor prioritization — fear that touching something working will break it. + +This fear is rational. AI tools that suggest refactors without verification have trained developers to be suspicious. You accept a suggestion, something subtle breaks, you spend two hours debugging it. You stop trusting automated refactoring on code that matters. + +The other reason is that refactoring doesn't appear on a roadmap. Features do. Bug fixes do. Refactoring is invisible work — it makes future work easier but produces nothing the business can point to immediately. Getting approval to spend a week on a module nobody is complaining about is a hard conversation. + +## What changes when verification is part of the process + +When a tool can prove that a change is safe before applying it — not roll back after the fact, but prevent the write entirely unless the proof exists — the risk calculation changes. + +The fear of breaking something working goes from "possible" to "systematically prevented." The test gate catches behavioral regressions before the filesystem is touched. Import integrity catches broken references before they reach runtime. Syntax validation catches structural corruption before it reaches anyone's editor. + +This doesn't make refactoring free or trivial. Complex structural changes still require human judgment. But it removes the specific fear that makes teams defer the obvious stuff indefinitely — renaming poorly named functions, removing dead code, simplifying conditionals that have accumulated branches over years of feature additions. + +That category of work — the obvious cleanup that teams know needs doing but won't touch — is where most of the velocity loss lives. + +## The compound interest argument + +Refactoring has compound returns in the same way technical debt has compound costs. + +A codebase that gets regular, safe, incremental cleanup is easier to work in next month than it is today. Easier to work in means faster feature development, fewer regressions, cheaper onboarding. The improvements are small individually and significant over a year. + +A codebase that doesn't get cleaned up is harder to work in next month than it is today. The compound is going in the wrong direction. + +The teams that build the fastest aren't the ones who defer cleanup until a dedicated "tech debt sprint" that never gets scheduled. They're the ones who make safe, incremental improvement a normal part of how code evolves — small changes, verified safe, applied continuously. + +\`\`\` +pip install refactron +refactron analyze . +\`\`\` + +Read-only. See what's accumulated. Nothing changes until you ask it to. + +--- + +### I Ran Refactron on FastAPI. Here's What It Found. + +*Published February 20, 2026 — https://refactron.dev/blog/refactron-on-fastapi* + +> FastAPI is the youngest codebase in this series — modern, well-typed, actively maintained. We're not looking at accumulated legacy complexity. We're looking at what complexity looks like in a well-designed modern Python codebase. + +FastAPI is the youngest codebase in this series. Sebastián Ramírez released the first version in 2018 — which makes it seven years old, modern by Python standards, and built from the start with type hints, async support, and a clean architecture in mind. + +It's also the fastest-growing Python web framework of the last three years. Which makes it an interesting contrast to Django and Requests. We're not looking at accumulated legacy complexity here. We're looking at what complexity looks like in a well-designed, actively maintained modern codebase. + +## Setup + +\`\`\` +git clone https://github.com/tiangolo/fastapi +cd fastapi +pip install refactron +refactron analyze . +\`\`\` + +Ran in under 12 seconds. + +## What it found + +The headline finding: FastAPI is genuinely clean. The type annotations are consistent, the module boundaries are clear, and the test coverage is solid. This is what well-maintained modern Python looks like and the analysis reflects it. + +That said, a few things surfaced. + +Complexity in the routing layer. fastapi/routing.py is doing a lot of work — parameter resolution, dependency injection, response model handling, exception routing. Each feature added to FastAPI over the years has left a trace here. The core routing functions have complexity scores that are elevated but not alarming. This is a known architectural tradeoff in framework design: the layer that coordinates everything else will always carry more complexity than the layers it coordinates. + +Deep conditional nesting in parameter handling. The code that resolves incoming request parameters into Python function arguments has several layers of nested conditionals. Again, this is inherent to what the code is doing — handling every combination of path params, query params, body params, headers, and cookies requires branching. Refactron surfaces it as a complexity signal. Whether it's worth addressing is a judgment call for the maintainers. + +A small number of long functions in the dependency injection system. Functions that handle dependency resolution end up being long because the logic is genuinely complex. These aren't candidates for automated decomposition — they're candidates for careful human refactoring with thorough test coverage, which FastAPI already has. + +## The autofix run + +\`\`\` +refactron autofix . --verify --dry-run +\`\`\` + +Fewer actionable suggestions here than in the Requests run. FastAPI's codebase is younger and has had more consistent maintenance attention — the low-hanging fruit has already been addressed. + +The suggestions Refactron was confident proposing: a few unused imports in test utilities, one redundant variable assignment in an internal helper. Small, safe, uncontroversial. + +For everything structural it flagged and stopped. The routing and dependency injection code is too central to FastAPI's behavior to touch without deep context. The right call. + +## What the output looks like + +\`\`\` +✓ Analyzing fastapi/ + +Files analyzed: 44 +Issues found: 6 + +MEDIUM (3): + High cyclomatic complexity + routing.py:412 — score: 13 + routing.py:218 — score: 11 + dependencies/utils.py:89 — score: 10 + +LOW (3): + Unused imports + tests/test_dependency_overrides.py:4 + tests/_test_tutorial/test_first_steps.py:2 +\`\`\` + +Six issues in a well-maintained 44-file codebase. That's a meaningful baseline. + +## What this series is showing + +Three runs in — Django, Requests, FastAPI — a pattern is emerging. + +Well-maintained open-source Python codebases accumulate complexity in two predictable places: integration layers (the code that coordinates everything else) and test files (which get less maintenance attention than production code). Security issues, import problems, and dead code are largely absent because the maintainer community catches them. + +The implication for internal codebases is straightforward. If a widely-scrutinised open-source library has six issues after years of active maintenance, a three-year-old internal service with one or two maintainers and no external review will have considerably more — concentrated in exactly the same places, with fewer eyes to catch them. + +## Try it + +\`\`\` +pip install refactron +refactron analyze . +\`\`\` + +Next in this series: Flask — the oldest of the modern Python web frameworks, and probably the most interesting findings yet. + +--- + +### How to Safely Refactor Python Code You Didn't Write + +*Published March 12, 2026 — https://refactron.dev/blog/how-to-safely-refactor-python-code-you-didnt-write* + +> Every developer has inherited code they didn't write. A service built by someone who left the company. A module running in production since 2019 with no tests and no documentation. Here's a practical framework for touching it safely. + +Every developer has inherited code they didn't write. A service built by someone who left the company. A module that's been running in production since 2019 with no tests and no documentation. A function that everyone on the team is afraid to touch because nobody fully understands what it does. + +This is not an edge case. It's the normal condition of software development at any company older than three years. + +Refactoring code you wrote is hard enough. Refactoring code you didn't write — code whose full behavior you can't be certain of — is a different problem entirely. This post is about how to approach it without breaking things. + +## Why inherited code is different + +When you refactor code you wrote, you have implicit knowledge that doesn't exist in the file. You remember why you made that decision in 2022. You know which edge cases that conditional is handling. You know the function that looks unused actually gets called from a config file. + +With inherited code, that implicit knowledge is gone. What's left is the code itself, whatever tests exist (often fewer than you'd like), and whatever documentation exists (often none). + +This changes the risk profile of refactoring significantly. A change that looks safe based on reading the code might break a behavior that only exists in the original author's head — or in a production edge case that the tests don't cover. + +## The wrong approach: rewrite it + +The most common response to inheriting a messy codebase is the impulse to rewrite it. Start fresh, do it properly, fix everything at once. + +This almost always makes things worse. + +Joel Spolsky called this the single worst strategic mistake a software company can make, and the reasoning holds at the module level too. The existing code, messy as it is, encodes years of bug fixes, edge case handling, and implicit requirements. A rewrite throws all of that away. What you get back is cleaner code that breaks in ways the original code didn't — because the original code had already encountered and handled those situations. + +The right approach is incremental. + +## A practical framework for inherited code + +Step 1: Understand before you touch. + +Run static analysis before making any changes. You want a map of the codebase — where the complexity is concentrated, what the dependencies look like, where the security risks are. This is orientation, not action. + +\`\`\` +refactron analyze . +\`\`\` + +Read-only. Nothing changes. You get a prioritized list of issues with file names, line numbers, and severity levels. Now you know what you're dealing with. + +Step 2: Start with the safe, obvious changes. + +Unused imports, dead code, redundant variable assignments, obvious naming issues — these are low-risk, high-readability improvements that don't change behavior. They make the code easier to read while you're learning it. They're also the easiest to verify as safe. + +\`\`\` +refactron autofix . --verify +\`\`\` + +Every change passes three checks before it touches a file. If anything fails, the original is untouched. For low-risk changes like import cleanup, these checks run in under a second and pass reliably. + +Step 3: Work outward from the tests. + +Before touching anything structural, understand your test coverage. If coverage is low, the first real investment is writing tests for the behavior you're about to change — not the refactoring itself. Tests are what make structural changes safe. Without them, you're flying blind regardless of what tools you use. + +If the code has no tests at all — which is common in older internal services — start by writing characterization tests: tests that describe what the code currently does, not what you think it should do. These become your verification baseline. + +Step 4: Make one structural change at a time. + +The temptation is to clean everything at once. Resist it. One function, one module, one change at a time. Run verification after each one. Commit after each one. Build a record of what changed and why. + +This feels slow. It's not. The alternative — large refactoring sessions that produce large diffs that are hard to review and hard to roll back — is what creates incidents. + +Step 5: Document as you go. + +Every time you understand why a piece of code does something non-obvious, write it down. A comment, a docstring, a README section. The next person to touch this code — which might be you in six months — will thank you. This is how tribal knowledge stops being tribal. + +## The specific risks to watch for + +A few failure modes come up repeatedly when refactoring inherited Python code. + +Removing imports that look unused but aren't. Python's import system has side effects. An import that doesn't appear to be referenced in a file might be registering a plugin, configuring a logger, or loading a Django app. Removing it breaks things in ways that don't show up until runtime. Always check whether an import has side effects before treating it as dead code. + +Renaming functions that are called by strings. If a function is called via getattr(), a config file, or a serialized reference somewhere, renaming it in the code doesn't rename it everywhere it's referenced. The code looks fine, the tests pass, it breaks in production when a config value calls a function that no longer exists by that name. + +Changing default parameter values. Default parameters in Python are evaluated once at function definition, not at call time. Changing a default can change behavior in ways that are subtle and surprising, especially for mutable defaults like lists or dictionaries. + +Simplifying conditionals that encode business logic. A conditional that looks like it's testing the same thing twice might be testing two subtly different things that happen to look the same. Before simplifying, understand what each branch is actually doing. + +## The mindset shift + +Refactoring inherited code safely is less about the tools and more about the mindset. The goal isn't a clean codebase — it's a codebase that works now and is slightly easier to work with than it was before. Progress, not perfection. + +Every small, safe, verified improvement compounds. Three months of incremental cleanup looks completely different from three months of deferred cleanup — not because any individual change was dramatic, but because they accumulate. + +The code you inherited didn't get messy overnight. It won't get clean overnight either. The teams that manage this best are the ones who make safe incremental improvement a habit, not a project. + +\`\`\` +pip install refactron +refactron analyze . +\`\`\` + +Start with understanding. Nothing changes until you ask it to. + +--- + +### Why We Built Refactron to Run Locally — Your Code Stays on Your Machine + +*Published April 2, 2026 — https://refactron.dev/blog/why-refactron-runs-locally* + +> Cloud-based AI tools process your code on external servers. We chose a different architecture — and here is why that decision matters for teams working on production codebases. + +When we were deciding how to architect Refactron, one of the earliest and most consequential decisions we made was this: the tool would run entirely on your machine. Your code would never touch our servers. Not for analysis, not for refactoring, not for verification. + +This was not the obvious choice. Cloud-based processing would have made certain things easier to build. It would have made the business model simpler — usage metrics, centralized telemetry, the ability to improve our models on real codebases over time. Almost every competitor in this space processes your code in the cloud because it gives them leverage. + +We chose not to. Here is why. + +## The problem with sending your code to someone else's server + +When you use a cloud-based AI coding tool, here is what happens in practice. + +You paste a function, or connect a repository, or let the tool run against your codebase. That code — your payment processing logic, your authentication layer, your proprietary business rules — travels to an external server. It gets processed by a model. A response comes back. + +What happens to it in between is, in most cases, not fully transparent. Terms of service vary. Data retention policies vary. What gets logged, what gets used for model training, what gets stored — these are questions that most developers using these tools have never actually read the answer to. + +For personal projects this is a tolerable risk. For production codebases at companies where code is a competitive asset, it is a different calculation entirely. Many engineering teams at regulated companies — finance, healthcare, defense adjacent — cannot use cloud-based AI coding tools at all because their legal and compliance teams will not allow it. Not because the tools are bad, but because sending proprietary code to an external server is a policy violation regardless of what the tool does with it. + +## What local-first actually means + +Refactron installs as a CLI tool via pip. When you run refactron analyze ., the analysis happens on your machine using your local Python environment. The AST parsing, the static analysis, the rule evaluation — all of it runs locally. + +When you run refactron autofix . --verify, the verification engine runs locally. The three checks — syntax validation, import integrity, and the test suite gate — all execute in your local environment against your local test suite. The result that determines whether a file gets modified is computed locally. + +Nothing about your code is transmitted anywhere. The only thing that touches our servers is authentication — confirming your API key is valid — and even that contains no code, no file paths, no analysis results. + +Your code stays on your machine. That is not a marketing claim. It is how the architecture works. + +## Why this matters more than most teams realize + +The conversation about AI coding tools and code security usually focuses on the dramatic scenarios — a breach, a leak, a public incident. Those scenarios are real but they are not the primary risk. + +The primary risk is quieter. It is that code which represents real competitive advantage — the pricing logic, the fraud detection model, the recommendation algorithm — leaves the building without anyone making a deliberate decision that it should. It leaves because a developer used a helpful tool, because the default behavior of the tool is to process code in the cloud, and because no one thought to check. + +Local-first architecture removes this risk by default. There is no opt-in required. There is no setting to configure. Code simply does not leave the machine because the tool does not have a mechanism to send it anywhere. + +## The compliance argument + +For teams working in regulated environments, this distinction is not a nice-to-have. It is what determines whether a tool can be used at all. + +Security teams evaluating developer tooling ask a consistent set of questions. Does this tool transmit source code? To whom? Under what terms? What is the data retention policy? Is it SOC 2 compliant? Can it be used in our air-gapped environment? + +Refactron's answers to these questions are straightforward. It does not transmit source code. There is no retention policy for source code because there is no source code to retain. It works in air-gapped environments because it has no runtime dependency on external servers. The compliance conversation is short because there is very little to evaluate. + +This is not something most AI coding tools can say. + +## The tradeoff we made + +We are honest about what local-first costs. Cloud-based tools can improve continuously by learning from the codebases they process. They can offer suggestions that are informed by patterns seen across millions of repositories. They can get smarter over time in ways that a purely local tool cannot. + +Refactron's analysis is deterministic and rule-based. It finds what its analyzers are designed to find. It does not learn from your codebase in ways that accumulate over time. The tradeoffs are real. + +We made this choice deliberately because we believe the developers who most need a safe refactoring tool — the engineers maintaining production codebases that represent years of accumulated work — are exactly the developers who cannot afford to have that code processed externally. Safety-first means local-first. The two are not separable. + +## What this means in practice + +\`\`\` +pip install refactron +refactron analyze . +\`\`\` + +Everything that happens after that command runs on your machine. The output you see is generated locally. The issues it finds are found locally. When you run autofix with verification, every check that determines whether your file is modified runs locally. + +Your codebase stays yours. + +--- + +### Refactron Is Now a Node.js Package. Here's Why That Changes Everything. + +*Published April 6, 2026 — https://refactron.dev/blog/refactron-is-now-a-nodejs-package* + +> Refactron v2.0 is a TypeScript rewrite distributed as an npm package. Same verification guarantees, new blast radius analysis, temporal safety intelligence, and support for both Python and TypeScript codebases. + +When we shipped Refactron to PyPI last year, the positioning was deliberate: safety-first refactoring for Python production codebases. Python only. One language, done properly. + +That boundary made sense at the time. The verification engine — the three checks that prove a change is safe before touching the filesystem — was built on Python-native tools. libcst for CST validation. importlib for import integrity. pytest for the test gate. The moat was real but it was also Python-shaped. + +We've been rethinking that. + +Not the moat — that stays. Every change must still pass syntax validation, import integrity, and your test suite before a single file is written. The atomic write protocol doesn't change. The inviolable rule doesn't change. + +What changes is the language the tool speaks. + +## What we're building + +Refactron v2.0 is a TypeScript rewrite, distributed as an npm package, designed to work on any codebase regardless of language. + +\`\`\` +npm install -g refactron +\`\`\` + +The commands are identical to the Python version. The verification pipeline is identical. The safety guarantees are identical. What's different is everything underneath — and one genuinely new capability that the Python version couldn't have. + +## Why TypeScript + +The Python package worked. The verification engine worked. The analysis worked. But the internals were messy in ways that made adding new language support harder than it needed to be. + +TypeScript as the orchestration layer changes the architecture in a meaningful way. The core verification engine calls an adapter interface. The adapter handles the language-specific tools as subprocesses. Adding Go support means writing one new adapter file. The verification engine, the CLI, the pipeline — none of it changes. + +This is the language adapter pattern and it's the right architecture for a tool that wants to work on any production codebase, not just Python ones. + +The Python tools still run for Python code. When you point Refactron at a .py file, it still calls python3 -c "import ast; ast.parse(...)" for syntax validation. It still runs pytest for the test gate. Nothing about the Python verification changes — it just runs as a subprocess now, which is cleaner. + +TypeScript and JavaScript codebases get the TypeScript compiler for syntax and import checks, and jest or vitest for the test gate. The output format is identical. The verification result contract is the same. + +## The new thing: blast radius + +The Python package told you what was wrong with a file. The TypeScript rewrite tells you something the Python version couldn't: how much of your codebase would be affected if a fix went wrong. + +We call it blast radius. + +Before any fix is applied, Refactron builds two graphs from your project's AST — a reverse import graph and a function-level call graph. It walks those graphs transitively to find every file, every function, and every test that depends on the code being changed. + +Then it shows you: + +\`\`\` +HIGH process_payment() — cyclomatic complexity 18 + Blast radius: 23 files · 41 functions · 6 test files + ████████████████░░░░ CRITICAL — touch with extreme care + +LOW validateCard() — missing return type + Blast radius: 3 files · 4 functions · 1 test file + ████░░░░░░░░░░░░░░░░ LOW — safe to autofix +\`\`\` + +This changes how you prioritize. Not "this function is complex" but "this function is complex and 23 other files depend on it." That's a genuinely different piece of information. + +The blast radius also changes how strict the verification engine is. A TRIVIAL blast radius — zero dependents, cosmetic change — runs a syntax check only, fast path under 50ms. A CRITICAL blast radius runs all three checks with a 2-minute test timeout and won't apply the fix unless confidence is above 97%. The safety guarantee scales with the actual risk. + +## Temporal safety intelligence + +The second new capability uses something you already have: your git history. + +Refactron parses git log per file and computes three signals — change velocity (how many times this file was modified in the last 6 months), days since last touch, and co-change pairs (files that always change together, a hidden coupling signal). + +A function with a high blast radius that hasn't been touched in two years and has a change velocity near zero gets a DANGER flag. Not because the code is necessarily broken, but because nobody has looked at it recently, everything depends on it, and touching it without full verification is exactly how production incidents happen. + +This costs nothing. No API calls. No external services. It runs on your local git history in under a second. + +## What the npm distribution means + +Python developers who already use Refactron: nothing changes. pip install refactron continues to work. The PyPI package stays maintained. + +TypeScript and JavaScript developers who couldn't use Refactron before: npm install -g refactron now gives you the same verification guarantees. + +For mixed codebases — Python backend, TypeScript frontend — point Refactron at the whole repository: + +\`\`\` +refactron analyze . + +Detected Python 3.11 · TypeScript 5.2 +Scanning ████████████████████ 131 files · 1.2s + +── Python ───────────────────────────────── +CRITICAL (1): SQL Injection · src/api/views.py:47 + Blast radius: 23 files · CRITICAL + +── TypeScript ───────────────────────────── +HIGH (2): Any type assertion · src/dashboard/UserView.tsx:124 + Blast radius: 7 files · MEDIUM +\`\`\` + +One command. Both languages. Issues grouped by language with their blast radii. + +## What stays exactly the same + +The verification engine has not changed. The three-check pipeline — syntax, imports, test gate — still runs before any file is modified. The atomic write still uses the temp-file-then-rename pattern. The original file is still never touched unless safe_to_apply is true. + +The moat is the same. The architecture that delivers it is better. + +## What's still Python-only + +The v2.0 npm package ships with two language adapters: Python and TypeScript. JavaScript (.js, .jsx) is included in the TypeScript adapter. Other languages — Go, Rust, Java — are on the roadmap but not in v2.0. + +If your codebase is Python only, the npm package works. If it's TypeScript only, the npm package works. If it's mixed, the npm package works. If it's Go — not yet. + +## Try it + +\`\`\` +npm install -g refactron +refactron analyze . +\`\`\` + +Analysis is read-only. It won't change anything. See what's there, see the blast radius on each issue, see which ones are safe to autofix. + +When you're ready: + +\`\`\` +refactron autofix . --verify +\`\`\` + +Everything that passes gets applied. Everything that would break something gets blocked with an explanation. Your original files are untouched until there's proof of safety. + +That's the same guarantee it's always been. Now it works on more of your codebase. + +--- diff --git a/public/llms.txt b/public/llms.txt new file mode 100644 index 0000000..4b5e545 --- /dev/null +++ b/public/llms.txt @@ -0,0 +1,35 @@ +# Refactron + +> Refactron is a deterministic, behavior-preserving refactoring engine for legacy code. No LLM in the loop. Every change is verified before it touches disk. Runs locally; nothing is sent to external services. + +Refactron is built for developers who maintain production codebases and need to evolve legacy code without breaking it. The analysis surfaces architectural debt (circular dependencies, duplicated code, deprecated APIs, missing type hints, callback-based async, etc.); the refactoring engine applies deterministic, idempotent transforms; verification gates (syntax → imports → tests → invariants) run before any file is rewritten; rollback is a single command. + +Refactron is **not** an LLM-based code generator. The engine is rule-based and deterministic — given the same input, it produces the same output. This is the moat: predictability, reviewability, and provability. + +- Language support: Python, TypeScript, JavaScript today. Go, Rust, and Java are on the roadmap. +- Install: `pip install refactron` or `npm install -g refactron`. +- Locality: runs entirely on your machine; no telemetry by default. +- Founder: Om Sherikar. Bengaluru, India. Built solo. + +## Docs + +- [Refactron — landing](https://refactron.dev/): Hero, pipeline, comparison with Cursor / SonarQube / CodeAnt, quickstart, FAQ. +- [About Refactron](https://refactron.dev/about): The origin story (the hackathon moment), the founder, and the five safety constraints (read-only first, human-in-the-loop, verification, incremental steps, rollback). +- [Security](https://refactron.dev/security): Privacy practices, encryption, local-first architecture, responsible-disclosure policy. +- [Research](https://refactron.dev/research): The technical paper on deterministic refactoring + behavior-preservation. +- [Changelog](https://refactron.dev/changelog): Release history and recent shipped features. +- [Blog](https://refactron.dev/blog): Case studies running Refactron on real open-source codebases (Django, FastAPI, etc.) and technical deep-dives. + +## Examples + +- [I Ran Refactron on Django's Codebase](https://refactron.dev/blog/i-ran-refactron-on-djangos-codebase): 300,000+ LOC, 18 years of Python contributors — what the analyzer surfaced. +- [Quickstart](https://refactron.dev/#quickstart): Install, analyze, preview refactors, apply with verification — 60 seconds end-to-end. +- [Pipeline overview](https://refactron.dev/#workflows): Analyze → Refactor → Verify → Document. Each stage is independently inspectable. + +## Optional + +- [Privacy Policy](https://refactron.dev/privacy-policy) +- [Terms of Service](https://refactron.dev/terms-of-service) +- [PyPI package](https://pypi.org/project/refactron/) +- [GitHub organisation](https://github.com/refactron-ai) +- [LinkedIn](https://www.linkedin.com/company/refactron) diff --git a/public/robots.txt b/public/robots.txt index ad983dd..63bee8f 100644 --- a/public/robots.txt +++ b/public/robots.txt @@ -1,24 +1,66 @@ -# Refactron Website - Robots.txt +# Refactron Website — robots.txt # https://refactron.dev -# Default rules for all crawlers -User-agent: * +# ─── AI / LLM crawlers ─────────────────────────────────────────── +# Refactron wants to be discoverable in AI search results AND +# referenced in foundation-model knowledge. We explicitly allow +# both retrieval and training bots. + +# Retrieval bots (live AI search — answer engines) +User-agent: OAI-SearchBot +Allow: / +User-agent: ChatGPT-User +Allow: / +User-agent: Claude-SearchBot +Allow: / +User-agent: Claude-Web +Allow: / +User-agent: PerplexityBot +Allow: / +User-agent: Perplexity-User +Allow: / +User-agent: Applebot-Extended +Allow: / +User-agent: YouBot Allow: / -Disallow: /api/ -Disallow: /_next/ -Disallow: /static/js/*.map -Disallow: /static/css/*.map -# Sitemap -Sitemap: https://refactron.dev/sitemap.xml +# Training bots (long-term LLM memory) +User-agent: GPTBot +Allow: / +User-agent: ClaudeBot +Allow: / +User-agent: anthropic-ai +Allow: / +User-agent: Google-Extended +Allow: / +User-agent: Meta-ExternalAgent +Allow: / +User-agent: CCBot +Allow: / +User-agent: Bytespider +Allow: / +User-agent: cohere-ai +Allow: / +User-agent: cohere-training-data-crawler +Allow: / +User-agent: Diffbot +Allow: / +User-agent: FacebookBot +Allow: / -# Allow all crawlers to access all content +# ─── Default rules for all other crawlers ──────────────────────── +User-agent: * +Allow: / Allow: /css/ Allow: /js/ Allow: /images/ Allow: /static/ +Disallow: /api/ +Disallow: /_next/ +Disallow: /static/js/*.map +Disallow: /static/css/*.map -# Specific bot instructions for major search engines +# ─── Search engine crawlers (explicit polite settings) ─────────── User-agent: Googlebot Allow: / Crawl-delay: 1 @@ -46,17 +88,7 @@ User-agent: YandexBot Allow: / Crawl-delay: 2 -# Block AI training bots (optional - uncomment if needed) -# User-agent: GPTBot -# Disallow: / - -# User-agent: CCBot -# Disallow: / - -# User-agent: anthropic-ai -# Disallow: / - -# Block common bad bots +# ─── Blocked: SEO-tool scrapers ────────────────────────────────── User-agent: AhrefsBot Disallow: / @@ -66,5 +98,9 @@ Disallow: / User-agent: MJ12bot Disallow: / +# ─── Sitemaps + LLM index ──────────────────────────────────────── +Sitemap: https://refactron.dev/sitemap.xml +Sitemap: https://refactron.dev/llms.txt + # Host directive Host: refactron.dev diff --git a/public/sitemap.xml b/public/sitemap.xml index 43f4325..1d27c71 100644 --- a/public/sitemap.xml +++ b/public/sitemap.xml @@ -1 +1 @@ -https://refactron.dev/weekly1.0https://refactron.dev/blogweekly0.9https://refactron.dev/aboutmonthly0.6https://refactron.dev/changelogweekly0.7https://refactron.dev/securitymonthly0.5https://refactron.dev/privacy-policyyearly0.3https://refactron.dev/terms-of-serviceyearly0.3https://refactron.dev/blog/i-ran-refactron-on-djangos-codebasemonthly0.8https://refactron.dev/blog/refactron-vs-cursor-vs-codeantmonthly0.8https://refactron.dev/blog/why-we-built-verification-engine-firstmonthly0.8https://refactron.dev/blog/legacy-code-ai-refactoringmonthly0.8https://refactron.dev/blog/refactron-on-requests-librarymonthly0.8https://refactron.dev/blog/real-cost-of-not-refactoringmonthly0.8https://refactron.dev/blog/refactron-on-fastapimonthly0.8https://refactron.dev/blog/how-to-safely-refactor-python-code-you-didnt-writemonthly0.8https://refactron.dev/blog/why-refactron-runs-locallymonthly0.8https://refactron.dev/blog/refactron-is-now-a-nodejs-packagemonthly0.8 \ No newline at end of file +https://refactron.dev/weekly1.0https://refactron.dev/blogweekly0.9https://refactron.dev/aboutmonthly0.6https://refactron.dev/changelogweekly0.7https://refactron.dev/securitymonthly0.5https://refactron.dev/researchmonthly0.5https://refactron.dev/privacy-policyyearly0.3https://refactron.dev/terms-of-serviceyearly0.3https://refactron.dev/blog/i-ran-refactron-on-djangos-codebasemonthly0.8https://refactron.dev/blog/refactron-vs-cursor-vs-codeantmonthly0.8https://refactron.dev/blog/why-we-built-verification-engine-firstmonthly0.8https://refactron.dev/blog/legacy-code-ai-refactoringmonthly0.8https://refactron.dev/blog/refactron-on-requests-librarymonthly0.8https://refactron.dev/blog/real-cost-of-not-refactoringmonthly0.8https://refactron.dev/blog/refactron-on-fastapimonthly0.8https://refactron.dev/blog/how-to-safely-refactor-python-code-you-didnt-writemonthly0.8https://refactron.dev/blog/why-refactron-runs-locallymonthly0.8https://refactron.dev/blog/refactron-is-now-a-nodejs-packagemonthly0.8 \ No newline at end of file diff --git a/scripts/generate-llms-full.js b/scripts/generate-llms-full.js new file mode 100644 index 0000000..1668e23 --- /dev/null +++ b/scripts/generate-llms-full.js @@ -0,0 +1,193 @@ +/* + * Generates public/llms-full.txt — a single Markdown document + * that concatenates the highest-signal site content for LLM + * ingestion. Runs at prebuild, mirrors generate-sitemap.js. + * + * Source pages (parsed via regex — no ts-node): + * - src/data/posts.ts → every blog post (title, summary, body) + * - src/components/FAQSection.tsx → FAQ Q/A pairs + * + * Static content (product overview, safety constraints) is baked + * into this script so the LLM doc stays curated rather than scraped. + */ + +const fs = require('fs'); +const path = require('path'); + +const ROOT = path.join(__dirname, '..'); + +/* ─── Static, hand-curated copy ───────────────────────────────── */ + +const OVERVIEW = `# Refactron + +> Deterministic, behavior-preserving refactoring engine for legacy code. No LLM in the loop. Every change is verified before it touches disk. Runs entirely locally. + +Refactron is a refactoring tool for production codebases. It analyzes architectural debt (circular imports, duplicated code, deprecated APIs, missing type hints, callback-based async), applies deterministic rule-based transforms, and runs verification gates (syntax / imports / tests / invariants) before any file is rewritten. Rollback is a single command. Same input, same output — that's the moat. + +It is **not** an LLM-based code generator. The engine is rule-based. Refactron does not send code to any external service by default. + +- Languages: Python, TypeScript, JavaScript (today); Go, Rust, Java on the roadmap. +- Install: \`pip install refactron\` (Python) or \`npm install -g refactron\` (Node). +- Locality: runs on your machine; telemetry disabled by default. +- Founder: Om Sherikar (Bengaluru, India). Built solo. +- Distribution: 3,500+ PyPI downloads with no paid marketing. +- Recognition: India Ascends — Lightspeed; F6S founder grant. + +## How Refactron works (pipeline) + +1. **Analyze.** Map every import edge. Surface legacy patterns across the full dependency tree without modifying any files. +2. **Refactor.** Apply deterministic transforms. Behavior is mathematically preserved across each transform. +3. **Verify.** Run syntax checks, import validation, and the existing test suite. If any gate fails, the original file is untouched. +4. **Document.** Auto-generate inline docs, changelogs, and function-level summaries after every verified refactor. + +## Safety constraints (the five guarantees) + +1. **Read-only analysis by default.** Refactron scans and reports first. Nothing is written until you explicitly approve a change. +2. **Human-in-the-loop refactoring.** Every change requires explicit developer approval — like a PR review. +3. **Verification to preserve behavior.** Automated checks confirm functional equivalence: syntax, imports, tests, invariants. +4. **Small, incremental changes.** Refactor in scoped, reviewable steps. Never a one-shot rewrite. +5. **Rollback support.** Undo any changeset with a single command. No git required. + +## How Refactron compares + +| Capability | Refactron | Cursor | SonarQube | CodeAnt | +| -------------------------------- | --------- | ------ | --------- | ------- | +| Finds legacy code | yes | no | no | no | +| Refactors it structurally | yes | no | no | no | +| No LLM in the engine | yes | no | yes | no | +| Verifies safety before write | yes | no | no | no | +| Generates docs after refactor | yes | no | no | no | +| Runs fully local | yes | no | no | no | + +Cursor and CodeAnt lean on LLMs (non-deterministic). SonarQube analyzes but does not refactor. Refactron analyzes, refactors deterministically, and verifies before write. +`; + +const ORIGIN_STORY = `## Origin + +At a hackathon, Om Sherikar watched a team avoid an entire part of their codebase. Nobody wanted to risk breaking it. He couldn't find a tool that would actually go in, fix the legacy code, and prove nothing broke. So he built one. + +That's the gap Refactron exists to close. The tools that existed could *find* legacy code or *generate* new code. None of them could actually *refactor* the old code and *prove* it was safe. +`; + +/* ─── Parsers ─────────────────────────────────────────────────── */ + +function parseBlogPosts() { + const file = fs.readFileSync( + path.join(ROOT, 'src/data/posts.ts'), + 'utf-8' + ); + + // Slice from `blogPosts: BlogPost[] = [` to the closing `];` + const startIdx = file.indexOf('export const blogPosts'); + const end = file.length; + const region = file.slice(startIdx, end); + + // Match each post object using a coarse but reliable split: + // each post starts with `{` after a comma or `[`, has slug/title/summary/body, + // ends before the next post's leading `,\n {`. + // We use the proven approach: pull each field individually with regex. + + const slugRx = /slug:\s*['"]([^'"]+)['"]/g; + const titleRx = /title:\s*["'](.+?)["'],/g; + const summaryRx = /summary:\s*\n?\s*['"]([\s\S]*?)['"],\n/g; + const bodyRx = /body:\s*`([\s\S]*?)`,?\n\s*(?:featured|}|\])/g; + const publishedRx = /publishedAt:\s*['"]([^'"]+)['"]/g; + + const slugs = [...region.matchAll(slugRx)].map(m => m[1]); + const titles = [...region.matchAll(titleRx)].map(m => m[1]); + const summaries = [...region.matchAll(summaryRx)].map(m => m[1]); + const bodies = [...region.matchAll(bodyRx)].map(m => m[1]); + const dates = [...region.matchAll(publishedRx)].map(m => m[1]); + + const n = Math.min( + slugs.length, + titles.length, + summaries.length, + bodies.length, + dates.length + ); + + const posts = []; + for (let i = 0; i < n; i++) { + posts.push({ + slug: slugs[i], + title: titles[i].replace(/\\(.)/g, '$1'), + summary: summaries[i].replace(/\\(.)/g, '$1').trim(), + body: bodies[i].trim(), + publishedAt: dates[i], + }); + } + return posts; +} + +function parseFaqs() { + const file = fs.readFileSync( + path.join(ROOT, 'src/components/FAQSection.tsx'), + 'utf-8' + ); + const region = file.slice(file.indexOf('const faqs')); + const qRx = /question:\s*['"](.+?)['"],/g; + const aRx = /answer:\s*\n?\s*['"]([\s\S]*?)['"],\n/g; + const questions = [...region.matchAll(qRx)].map(m => m[1]); + const answers = [...region.matchAll(aRx)].map(m => m[1]); + const n = Math.min(questions.length, answers.length); + const out = []; + for (let i = 0; i < n; i++) { + out.push({ + question: questions[i].replace(/\\(.)/g, '$1'), + answer: answers[i].replace(/\\(.)/g, '$1').trim(), + }); + } + return out; +} + +/* ─── Assemble ────────────────────────────────────────────────── */ + +function generate() { + const posts = parseBlogPosts(); + const faqs = parseFaqs(); + + const sections = []; + sections.push(OVERVIEW.trim()); + sections.push(ORIGIN_STORY.trim()); + + // FAQ + if (faqs.length) { + const faqMd = ['## Frequently asked questions', '']; + for (const f of faqs) { + faqMd.push(`### ${f.question}`); + faqMd.push(''); + faqMd.push(f.answer); + faqMd.push(''); + } + sections.push(faqMd.join('\n').trim()); + } + + // Blog posts + if (posts.length) { + const blogMd = ['## Blog — case studies and deep-dives', '']; + for (const p of posts) { + blogMd.push(`### ${p.title}`); + blogMd.push(''); + blogMd.push(`*Published ${p.publishedAt} — https://refactron.dev/blog/${p.slug}*`); + blogMd.push(''); + blogMd.push(`> ${p.summary}`); + blogMd.push(''); + blogMd.push(p.body); + blogMd.push(''); + blogMd.push('---'); + blogMd.push(''); + } + sections.push(blogMd.join('\n').trim()); + } + + const out = sections.join('\n\n\n') + '\n'; + const outPath = path.join(ROOT, 'public/llms-full.txt'); + fs.writeFileSync(outPath, out); + + console.log( + `✓ llms-full.txt — ${posts.length} blog posts + ${faqs.length} FAQs → public/llms-full.txt (${out.length.toLocaleString()} bytes)` + ); +} + +generate(); diff --git a/scripts/generate-sitemap.js b/scripts/generate-sitemap.js index 9ebc4a2..8e11baf 100644 --- a/scripts/generate-sitemap.js +++ b/scripts/generate-sitemap.js @@ -19,6 +19,7 @@ const staticRoutes = [ { url: '/about', changefreq: 'monthly', priority: 0.6 }, { url: '/changelog', changefreq: 'weekly', priority: 0.7 }, { url: '/security', changefreq: 'monthly', priority: 0.5 }, + { url: '/research', changefreq: 'monthly', priority: 0.45 }, { url: '/privacy-policy', changefreq: 'yearly', priority: 0.3 }, { url: '/terms-of-service',changefreq: 'yearly', priority: 0.3 }, // blog posts added dynamically below diff --git a/scripts/prerender.js b/scripts/prerender.js index 908bd86..4834909 100644 --- a/scripts/prerender.js +++ b/scripts/prerender.js @@ -31,6 +31,7 @@ const PAGES = [ '/about', '/changelog', '/security', + '/research', '/privacy-policy', '/terms-of-service', ...blogSlugs.map(slug => `/blog/${slug}`), diff --git a/src/App.tsx b/src/App.tsx index 5a3411a..c69690b 100644 --- a/src/App.tsx +++ b/src/App.tsx @@ -9,8 +9,11 @@ import { Analytics } from '@vercel/analytics/react'; import HeroSection from './components/HeroSection'; import RefactoringWorkflowSection from './components/RefactoringWorkflowSection'; import WhatWeDoSection from './components/WhatWeDoSection'; +import ComparisonSection from './components/ComparisonSection'; +import QuickstartSection from './components/QuickstartSection'; import PricingSection from './components/PricingSection'; import FAQSection from './components/FAQSection'; +import TestimonialsSection from './components/TestimonialsSection'; import BlogPage from './components/BlogPage'; import BlogPostPage from './components/BlogPostPage'; import AboutPage from './components/AboutPage'; @@ -28,6 +31,7 @@ import useAccessibility from './hooks/useAccessibility'; import PageLayout from './components/PageLayout'; import Changelog from './components/Changelog'; import SecurityPage from './components/SecurityPage'; +import ResearchPage from './components/ResearchPage'; import StatusPage from './components/StatusPage'; import { ThemeProvider } from './contexts/ThemeContext'; @@ -37,6 +41,9 @@ const LandingContent: React.FC = () => ( + + + @@ -146,6 +153,14 @@ function App() { } /> + + + + } + /> } /> +
+
+ +); + +/* Inline static dot-grid backdrop matching the rest of the site. */ +const DotGridBackdrop: React.FC<{ opacity?: number }> = ({ + opacity = 0.35, +}) => ( +
+); + +/* ─── ASCII backdrop ───────────────────────────────────────────── + * A deliberately beautiful character-pattern backdrop. Two layers: + * - "mist" — dense, faint scatter of punctuation glyphs. + * - "stars" — sparse, brighter accents. + * Both are generated once at module load with a seeded RNG so the + * pattern is stable. Density rises with distance from the centre + * so the foreground content stays readable. A radial mask fades + * both layers toward the centre. + */ + +const ASCII_MIST_CHARS = '·.:,;-_=/<>()[]{}|'; +const ASCII_STAR_CHARS = '01░▒+*✦'; +const ASCII_COLS = 180; +const ASCII_ROWS = 80; + +function buildAsciiPattern( + cols: number, + rows: number, + chars: string, + seed: number, + centerSparsity: number, + edgeDensity: number +): string { + let s = seed >>> 0; + const rng = () => { + s = (s * 1664525 + 1013904223) >>> 0; + return s / 4294967296; + }; + const lines: string[] = []; + for (let r = 0; r < rows; r++) { + let row = ''; + for (let c = 0; c < cols; c++) { + const dx = (c - cols / 2) / (cols / 2); + const dy = (r - rows / 2) / (rows / 2); + const dist = Math.min(1, Math.sqrt(dx * dx + dy * dy)); + /* spaceP = probability of placing a SPACE; high in the centre. */ + const spaceP = centerSparsity - dist * edgeDensity; + if (rng() < spaceP) { + row += ' '; + } else { + row += chars[Math.floor(rng() * chars.length)]; + } + } + lines.push(row); + } + return lines.join('\n'); +} + +const ASCII_MIST = buildAsciiPattern( + ASCII_COLS, + ASCII_ROWS, + ASCII_MIST_CHARS, + 1234567, + 0.92, + 0.55 +); + +const ASCII_STARS = buildAsciiPattern( + ASCII_COLS, + ASCII_ROWS, + ASCII_STAR_CHARS, + 98765432, + 0.995, + 0.04 +); + +const AsciiBackdrop: React.FC<{ + /** Radial mask centre; defaults to the headline area on the left. */ + maskAt?: string; +}> = ({ maskAt = '50% 50%' }) => { + const mask = `radial-gradient(ellipse 75% 60% at ${maskAt}, transparent 0%, rgba(0,0,0,0.55) 55%, black 100%)`; + return ( +
+ + + {/* Mist layer */} + 
+        {ASCII_MIST}
+
+ + {/* Stars layer */} + 
+        {ASCII_STARS}
+
+
+ ); +}; + +/* ─── Hands-reaching ASCII backdrop ────────────────────────────── + * Two tapering blades sweep in from opposite corners, almost + * touching in the centre — the Creation-of-Adam composition. Each + * cell's character is chosen from a density palette (▓ ▒ ░ · ' ') + * based on its signed-distance to the nearest blade's spine. + * Deterministic — built once at module load. + */ + +interface HandBlade { + /** Origin point in screen units (col, row*2). Usually off-canvas. */ + ax: number; + ay: number; + /** Fingertip point. */ + bx: number; + by: number; + /** Half-width at the origin (wrist). */ + thickStart: number; + /** Half-width at the fingertip. */ + thickEnd: number; +} + +const HAND_BLADES: HandBlade[] = [ + /* Left "arm" — sweeps in from lower-left, fingertip just left of centre */ + { ax: -8, ay: 78, bx: 78, by: 46, thickStart: 9.5, thickEnd: 0.6 }, + /* Right "arm" — sweeps in from upper-right, fingertip just right of centre */ + { ax: 168, ay: 22, bx: 84, by: 50, thickStart: 9.5, thickEnd: 0.6 }, +]; + +const HANDS_COLS = 160; +const HANDS_ROWS = 48; + +const HANDS_PATTERN: string = (() => { + let s = 271828 >>> 0; + const rng = (): number => { + s = (s * 1664525 + 1013904223) >>> 0; + return s / 4294967296; + }; + + const bladeSD = (c: number, r: number, b: HandBlade): number => { + const x = c; + const y = r * 2; /* char aspect correction */ + const dx = b.bx - b.ax; + const dy = b.by - b.ay; + const len2 = dx * dx + dy * dy; + const t = Math.max( + 0, + Math.min(1, ((x - b.ax) * dx + (y - b.ay) * dy) / len2) + ); + const closestX = b.ax + t * dx; + const closestY = b.ay + t * dy; + const ddx = x - closestX; + const ddy = y - closestY; + const dist = Math.sqrt(ddx * ddx + ddy * ddy); + const thickness = b.thickStart + (b.thickEnd - b.thickStart) * t; + return dist - thickness; + }; + + const lines: string[] = []; + for (let r = 0; r < HANDS_ROWS; r++) { + let row = ''; + for (let c = 0; c < HANDS_COLS; c++) { + const sd = Math.min( + bladeSD(c, r, HAND_BLADES[0]), + bladeSD(c, r, HAND_BLADES[1]) + ); + let ch: string; + if (sd < -4) ch = '▓'; + else if (sd < -2) ch = rng() < 0.6 ? '▓' : '▒'; + else if (sd < -0.5) ch = '▒'; + else if (sd < 0.4) ch = '░'; + else if (sd < 1.5) ch = rng() < 0.45 ? '·' : ' '; + else ch = ' '; + row += ch; + } + lines.push(row); + } + return lines.join('\n'); +})(); + +const HandsAsciiBackdrop: React.FC = () => { + /* Vignette: visible in the middle band where the reaching happens, + * fading at the corners so it never fights with the section edges. */ + const mask = + 'radial-gradient(ellipse 95% 78% at 50% 50%, black 35%, rgba(0,0,0,0.55) 78%, transparent 100%)'; + return ( +
+ 
+        {HANDS_PATTERN}
+
+
+ ); +}; + +/* ─── Data ────────────────────────────────────────────────────── */ + +const identityFields: { key: string; value: string }[] = [ + { key: 'role', value: 'founder · solo' }, + { key: 'building', value: 'refactron · v0.5.x' }, +]; + +const receipts: string[] = [ + '3,500+ PyPI downloads', + 'No paid marketing', + 'Industry beta users', + 'India Ascends · Lightspeed', + 'F6S founder grant', +]; + const safetyConstraints = [ { num: '01', title: 'Read-only analysis by default', description: 'No changes are made without explicit approval.', + outcomeLabel: 'Read-only first', + outcome: + 'Scan and understand the codebase first. Nothing is written until you choose to apply a change.', }, { num: '02', title: 'Human-in-the-loop refactoring', description: 'Every change requires explicit approval from developers.', + outcomeLabel: 'You approve every change', + outcome: + 'You review proposals like any other PR. Nothing lands without your sign-off.', }, { num: '03', title: 'Verification to preserve behavior', description: 'Automated checks ensure functional equivalence.', + outcomeLabel: 'Proof, not hope', + outcome: + 'Checks run against your tests and invariants so you see evidence before merge.', }, { num: '04', title: 'Small, incremental changes', description: 'Targeted improvements instead of large rewrites.', + outcomeLabel: 'Small, reviewable steps', + outcome: 'Each step stays scoped and clear instead of one risky sweep.', }, { num: '05', title: 'Rollback support', description: 'Clear documentation and easy reversal for every change.', + outcomeLabel: 'Walk it back', + outcome: 'Undo a changeset quickly when you need to reverse course.', }, ]; -const AboutPage: React.FC = () => { - const [activeCardIndex, setActiveCardIndex] = useState(0); +type DigestSeverity = 'err' | 'warn' | 'info'; + +const problemDigestRows: { + severity: DigestSeverity; + title: string; + detail: string; +}[] = [ + { + severity: 'err', + title: 'Circular dependency', + detail: 'module_a imports module_b; module_b imports module_a.', + }, + { + severity: 'warn', + title: 'Duplicated code', + detail: '847 lines duplicated across 12 files.', + }, + { + severity: 'warn', + title: 'High complexity', + detail: 'Cyclomatic complexity 28 (threshold 10).', + }, + { + severity: 'info', + title: 'Test coverage', + detail: '38% overall.', + }, + { + severity: 'err', + title: 'Technical debt', + detail: 'Overall risk flagged as high.', + }, +]; + +const approachSteps: { title: string; detail: string }[] = [ + { + title: 'Analyze the codebase', + detail: 'Structure and dependencies are mapped without modifying files.', + }, + { + title: 'Detect patterns', + detail: 'Architectural patterns and hotspots surface as readable findings.', + }, + { + title: 'Refactor opportunity', + detail: + 'Example: extract an interface (low risk) to reduce coupling between modules.', + }, + { + title: 'Verification', + detail: 'Behavior checks pass, including your existing test suite.', + }, + { + title: 'Ready for review', + detail: 'You get a clear diff and rationale before anything ships.', + }, +]; + +/* Bullet glyph — small monochrome marker for prose lists. */ +const ListMarker: React.FC = () => ( + +); + +/* Inline terminal-style severity token: [ERR] / [WARN] / [INFO]. */ +const SeverityToken: React.FC<{ severity: DigestSeverity }> = ({ + severity, +}) => { + const cfg = { + err: { label: 'ERR ', alpha: 0.9 }, + warn: { label: 'WARN', alpha: 0.62 }, + info: { label: 'INFO', alpha: 0.36 }, + }[severity]; + return ( + + {cfg.label} + + ); +}; + +/* ─── Tactile glassmorphic visuals for What Safe Means ──────────── + * Each constraint gets its own miniature "control surface" — a + * small CSS-built widget with a satin gradient, soft inset shadow, + * and a single iconic affordance. Same glass language as the hero + * chip module, scaled down per card. + */ + +/* Base recipes — reused across the five visuals. */ +const glassBase: React.CSSProperties = { + background: + 'linear-gradient(180deg, rgba(255,255,255,0.045) 0%, rgba(0,0,0,0.35) 100%)', + boxShadow: + 'inset 0 1px 0 rgba(255,255,255,0.08), inset 0 -1px 0 rgba(0,0,0,0.55), 0 6px 14px -4px rgba(0,0,0,0.55)', + border: '1px solid rgba(255,255,255,0.06)', +}; + +const glassActive: React.CSSProperties = { + background: + 'linear-gradient(180deg, rgba(255,255,255,0.13) 0%, rgba(255,255,255,0.02) 100%)', + boxShadow: + 'inset 0 1px 0 rgba(255,255,255,0.18), inset 0 -1px 0 rgba(0,0,0,0.5), 0 8px 16px -4px rgba(0,0,0,0.6), 0 0 22px -6px rgba(255,255,255,0.18)', + border: '1px solid rgba(255,255,255,0.18)', +}; + +const glassDim: React.CSSProperties = { + background: + 'linear-gradient(180deg, rgba(255,255,255,0.025) 0%, rgba(0,0,0,0.4) 100%)', + boxShadow: + 'inset 0 1px 0 rgba(255,255,255,0.05), inset 0 -1px 0 rgba(0,0,0,0.45), 0 4px 10px -3px rgba(0,0,0,0.4)', + border: '1px dashed rgba(255,255,255,0.14)', +}; + +/* 01 — Read-only first */ +const SafetyReadOnly: React.FC = () => ( +
+
+ + + READ + +
+ +
+ +
+ + WRITE + + +
+
+); + +/* 02 — You approve every change */ +const SafetyApprove: React.FC = () => ( +
+
+ + PROPOSED + + +
+ +
+ + + +
+ +
+ + APPROVED + + + + +
+
+); + +/* 03 — Proof, not hope */ +const SafetyVerify: React.FC = () => { + const rows = [ + { label: 'syntax', alpha: 0.95 }, + { label: 'tests', alpha: 0.9 }, + { label: 'invariants', alpha: 0.85 }, + ]; + return ( +
+ {rows.map((row, i) => ( +
+ + + {row.label} + + + pass + +
+ ))} +
+ ); +}; + +/* 04 — Small, reviewable steps */ +const SafetyIncremental: React.FC = () => { + const steps = [ + { alpha: 0.95, active: true }, + { alpha: 0.72, active: false }, + { alpha: 0.52, active: false }, + { alpha: 0.32, active: false }, + { alpha: 0.18, active: false }, + ]; + return ( +
+ {steps.map((s, i) => ( +
+ + {String(i + 1).padStart(2, '0')} + +
+ ))} +
+ ); +}; + +/* 05 — Walk it back */ +const SafetyRollback: React.FC = () => ( +
+ {/* Dashed arc trail behind */} + + + + +
+ {/* prev */} +
+ +
+ + {/* center — rollback button */} +
+ +
+ + {/* now */} +
+ +
+
+
+); + +const SafetyVisual: React.FC<{ num: string }> = ({ num }) => { + switch (num) { + case '01': + return ; + case '02': + return ; + case '03': + return ; + case '04': + return ; + case '05': + return ; + default: + return null; + } +}; + +/* ─── Hero glassmorphic chip module ────────────────────────────── + * Dark glass / satin-finish tile that reads as a single hardware + * module ("REFACTRON · ENGINE"). Soft top-edge highlight, inset + * shadow, subtle radial pulse on the core, a small mono logo + * glyph in the corner, an LED-style status row, and surrounding + * mono labels. Pure CSS — no SVG hairlines, no iso slabs. + */ + +const ChipCoreDie: React.FC = () => { + /* A 9x9 grid of dots that fade radially from the centre, + * suggesting a chip die seen from above. The centre pulses very + * subtly via a single CSS keyframe. */ + const cells: { alpha: number; emphasize: boolean }[] = []; + const N = 9; + for (let i = 0; i < N * N; i++) { + const r = Math.floor(i / N) - (N - 1) / 2; + const c = (i % N) - (N - 1) / 2; + const d = Math.sqrt(r * r + c * c); + const alpha = Math.max(0, 0.62 - d * 0.13); + cells.push({ alpha, emphasize: r === 0 && c === 0 }); + } + return ( +
+ {cells.map((cell, i) => ( + + ))} +
+ ); +}; + +const HeroChipModule: React.FC = () => ( +
+ {/* Inline pulse keyframe used by the core */} + + + {/* Surrounding mono labels */} +
+ FIG · 01 +
+
+ DETERMINISTIC · V0.5 +
+
+ ANALYZE · REFACTOR · VERIFY · DOCUMENT +
+ + {/* The chip */} +
+ {/* Top-edge soft highlight */} +
+ + {/* Top-right logo glyph */} +
+ + {/* Stylized "R" glyph */} + + +
+ + {/* Center die */} +
+
+ {/* Soft inner halo */} +
+
+ +
+
+
+ + {/* Bottom-left product label */} +
+
REFACTRON
+
ENGINE
+
+ {/* Bottom-right status LEDs — first one pulses (active) */} +
+ {[ + { a: 0.95, pulse: true }, + { a: 0.55, pulse: false }, + { a: 0.55, pulse: false }, + { a: 0.55, pulse: false }, + { a: 0.3, pulse: false }, + ].map((led, i) => ( + + ))} +
+
+
+); + +const AboutPage: React.FC = () => { useSEO({ title: 'About Refactron | Safety-First Refactoring Engine', description: - 'Refactron is a safety-first refactoring engine for evolving real-world codebases through structured, incremental, and behavior-preserving transformations.', + 'Every codebase has code nobody wants to touch. Refactron exists to change that: refactoring legacy code with verification so you know nothing broke.', keywords: 'safe refactoring, code evolution, technical debt, behavior-preserving transformation, incremental refactoring, code maintainability', ogTitle: 'About Refactron | Safety-First Refactoring Engine', ogDescription: - 'A safety-first refactoring engine for evolving real-world codebases with confidence.', + 'Every codebase has code nobody wants to touch. Built to refactor the old code and prove it stayed safe.', canonical: 'https://refactron.dev/about', robots: 'index, follow', }); return (
- {/* ─── Hero ─────────────────────────────────────────────────────────── */} -
- {/* Line grid — visible in center, fades on all four sides */} -
-
-
-
+ {/* ─── Hero ────────────────────────────────────────────────────── */} +
+ + {sectionFades} + +
-
-

- About Refactron +
+

+ Every codebase has code +
+ nobody wants to touch.

-
-
-

- A safety-first refactoring engine for evolving real-world - codebases through structured, incremental, and - behavior-preserving transformations. + +

+

+ Refactron exists to change that. +

+

+ Built so you can refactor the old code and{' '} + prove nothing broke. +

+
+ +

+ — Om Sherikar, founder

+ +
+ +

- {/* ─── The Problem ──────────────────────────────────────────────────── */} -
-
-
+ {/* ─── Founder + Origin Story ────────────────────────────────── */} +
+ + {sectionFades} +
+ +

Founder · Origin

+

+ Built by Om Sherikar. +

+ + + + + +
+ {/* Portrait */} +
+
+ Portrait of Om Sherikar, founder of Refactron +
+
+
+
+ Om Sherikar, founder of Refactron. +
+
+ + {/* Bio / origin story */} +
+ {/* Identity block — JSON-config feel */} +
+ {identityFields.map(f => ( +
+
+ {f.key}: +
+
{f.value}
+
+ ))} +
+ +
+ + {/* The moment */} +
+

+ The moment +

+

+ At a hackathon, I watched a team avoid an entire part of + their codebase. Nobody wanted to risk breaking it. That + moment stuck with me. +

+

+ I looked for a tool that would actually go in, fix the + legacy code, and prove nothing broke. Couldn't find + one. +

+

+ So I built one. +

+
+ + {/* Receipts */} +
    + {receipts.map(label => ( +
  • + {label} +
    • + ))} +
+ + {/* Social */} + +
+
+ +
+
+ + {/* ─── The Problem ──────────────────────────────────────────── */} +
+ {sectionFades}
- {/* Content */}
-

- The Problem +

Context

+

+ The Problem.

-

+

Most production codebases carry significant technical debt, but refactoring them is often avoided.

-
    +
      {[ - 'Manual refactoring is slow, expensive, and risky', - 'Automated tools focus on generation without guaranteeing correctness', - 'Teams postpone structural improvements, making codebases harder to maintain', + 'Manual refactoring is slow, expensive, and risky.', + 'Automated tools focus on generation without guaranteeing correctness.', + 'Teams postpone structural improvements, making codebases harder to maintain.', ].map((item, i) => (
    • - - → - - {item} + + {item}
      • ))}
    - {/* Visual */} -
    - -
    -
    - > ERROR: CircularDependencyDetected -
    -
    - > module_a imports module_b -
    -
    - > module_b imports module_a -
    -
    - > WARNING: DuplicatedCode -
    -
    - > 847 lines duplicated across 12 files -
    -
    - > WARNING: HighComplexity -
    -
    - > cyclomatic_complexity: 28 (threshold: 10) -
    -
    - > test_coverage: 38% -
    -
    - > technical_debt_ratio: HIGH -
    +
    + + + {/* Terminal header strip */} +
    + + + + + + + ~/legacy-monolith + + + 5 findings + +
    + + {/* Terminal body */} +
    +

    + ›  + refactron analyze . +

    +

    + ✓ scanned 1,284 files · 8.2s +

    + +
    + {problemDigestRows.map(row => ( +
    +
    + + [ + + + + ] + + + {row.title} + +
    +

    + {row.detail} +

    +
    + ))}
    - + +
    + ─{' '} + 2 errors + · + 2 warnings + · + 1 info +
    +
- {/* ─── Our Approach ─────────────────────────────────────────────────── */} -
-
-
+ {/* ─── My Approach ──────────────────────────────────────────── */} +
+ {sectionFades}
- {/* Visual */} -
- -
-
- > analyzing_codebase... -
-
- > dependency_graph: built -
-
- > architectural_patterns: detected -
-
- > refactor_opportunity_found: -
-
- > type: extract_interface -
-
- > impact: low_risk -
-
- > benefit: reduces_coupling -
-
- > verification: passed -
-
- > tests: all_green ✓ -
-
- > ready_for_review -
+
+ +
+

+ Analysis pipeline +

+ + {approachSteps.length} stages + +
+ + {/* Tiny pipeline overview — 5 dots connected by a hairline */} +
+ {approachSteps.map((_, i) => ( + + + {i < approachSteps.length - 1 && ( + + )} + + ))} +
+ + {/* Vertical pipeline with continuous connector line */} +
    + +
    + {approachSteps.map((step, i) => ( +
  1. + + {String(i + 1).padStart(2, '0')} + +
    +

    + {step.title} +

    +

    + {step.detail} +

    +
    +
    2. + ))}
    - +
- {/* Content */}
-

- Our Approach +

How I think about it

+

+ My Approach.

-

+

Refactoring as a structured engineering process, not a one-shot automation problem.

-
    +
      {[ - 'Analyzes code structure and identifies targeted improvements', - 'Proposes incremental refactors that preserve existing behavior', - 'Makes refactoring predictable, reviewable, and safe', + 'Analyzes code structure and identifies targeted improvements.', + 'Proposes incremental refactors that preserve existing behavior.', + 'Makes refactoring predictable, reviewable, and safe.', ].map((item, i) => (
    • - - → - - {item} + + {item}
      • ))}
    @@ -284,268 +1223,136 @@ const AboutPage: React.FC = () => {
- {/* ─── What "Safe" Means ────────────────────────────────────────────── */} -
-
-
+ {/* ─── What Safe Means ─────────────────────────────────────── */} +
+ {sectionFades}
- {/* Section header */} -
-

- What Safe Means -

-
-
-

- Safety is not a claim — it's a set of constraints Refactron is - built around. -

-
+

Principles

+

+ What Safe Means. +

+

+ Safety isn't a claim — it's a set of constraints I built + Refactron around. +

- {/* CardSwap layout */} -
- {/* Left: active constraint list */} - - {safetyConstraints.map((c, i) => ( - + {safetyConstraints.map((c, i) => { + const isLast = i === safetyConstraints.length - 1; + return ( +
-
-
- + + + {/* Top row: number + outcome chip */} +
+ {c.num} -
-

- {c.title} -

-

- {c.description} -

-
+ + {c.outcomeLabel} +
- - ))} -
- - {/* Right: CardSwap — relative container sized to fit the stack */} -
- - -
-
$ analyze.sh
-
→ Read-only mode: ON
-
- → Scanning 847 files... -
-
- → No changes written to disk -
-
- → Analysis complete ✓ -
-
- - -
-
$ refactor.sh
-
- → 3 refactor proposals ready -
-
- → Awaiting your approval... -
-
- [y] extract_interface: UserService -
-
- → Change applied ✓ -
-
- - -
-
$ verify.sh
-
- → Running behavior checks... -
-
- → Snapshot comparison: passed -
-
- → Test suite: 142/142 ✓ -
-
- → Semantic equivalence: confirmed ✓ -
+ {/* The visual */} +
+
- - -
-
- $ incremental.sh -
-
- → Scope: 1 class, 3 methods -
-
- → Lines changed: +12 / -8 -
-
- → No cross-module side effects -
-
- → Safe to apply ✓ -
-
- - -
-
$ rollback.sh
-
- → Reverting changeset abc123... -
-
→ Files restored: 3
-
→ State: clean ✓
-
- → Rollback complete in 0.3s -
+ + {/* Title + description */} +

+ {c.title} +

+

+ {c.description} +

+ + {/* Outcome — bottom anchored */} +
+

+ {c.outcome} +

- - -
-
+
+ ); + })} +
- {/* ─── Why We're Building Refactron ─────────────────────────────────── */} -
-
-
-
- + {sectionFades} +
+ - {/* Decorative large quote mark */} - + - {/* Left accent bar */} -
- -
-
- - Why We're Building Refactron - +
+

A letter

+ +

+ Why I'm building Refactron. +

+ +
+

+ The tools that existed could find legacy code, or generate new + code. None of them could{' '} + actually refactor the old + code and prove it was safe + . +

+

+ That gap bothered me enough that I couldn't leave it + alone. +

-
- - We've worked with long-lived, real-world codebases where - refactoring was necessary but often deferred because existing - tools didn't feel safe or trustworthy. Refactron is being - built to fill that gap — to make code evolution boring, - predictable, and repeatable, so teams can improve their - systems with confidence instead of fear. - - - {/* Three pillars */} - - {[ - { - label: 'Boring by design', - sub: 'No surprises. Ever.', - }, - { - label: 'Predictable', - sub: 'Every change is traceable.', - }, - { - label: 'Repeatable', - sub: 'Works the same way, always.', - }, - ].map(p => ( -
-
- {p.label} -
-
- {p.sub} -
-
- ))} - + +
+ + + Om +
- +
- {/* ─── Contact ──────────────────────────────────────────────────────── */} -
+ {/* ─── Contact ─────────────────────────────────────────────── */} +
-

- Questions or want to learn more? +

+ Questions, or want to learn more?

- Get in touch with us + Get in touch
diff --git a/src/components/BlogPostPage.tsx b/src/components/BlogPostPage.tsx index 8fe5719..79011ba 100644 --- a/src/components/BlogPostPage.tsx +++ b/src/components/BlogPostPage.tsx @@ -3,6 +3,65 @@ import { useNavigate, useParams } from 'react-router-dom'; import { motion } from 'framer-motion'; import { ArrowLeft, CalendarDays, Tag, User } from 'lucide-react'; import { getBlogPostBySlug, parseBody, ContentSection } from '../data/posts'; +import useSEO from '../hooks/useSEO'; + +/* Injects a per-post BlogPosting JSON-LD