The same @import("storage") can mean different things in two Zig executables. Drawing one global edge for that name gives you a very convincing wrong diagram.

In ArchUnitZig, my architecture-testing library, you can describe each compilation root and its module aliases separately. For example, the server's storage alias can point to the real persistence module while a test root maps it to a fake. Each gets its own resolution context.

The useful part is what happens when context is missing: an unknown named import stays visible as unresolved. It doesn't silently disappear from the graph or get guessed from a filename. @import("root") follows the selected compilation root too.

A slightly boring detail until you rely on the picture

This is explicit configuration. The tool doesn't execute build.zig and pretend it understands every build script. Once the mappings are there, you can use the graph for dependency rules, focused reports, or an offline HTML export.

It's free and MIT-licensed. The current v0.0.2 preview targets Zig 0.16.0: https://github.com/dragonsec-ai/ArchUnitZig

The public acceptance tests include separate application and integration-test roots, plus cases for unresolved aliases and resource imports.

no incident yet, but plenty of devs and power users here run coding agents straight on their workstations under their own accounts. getting people to try a sandbox once seems doable. i'm less sure they'll keep using it on a normal repo when they need private packages or their usual test setup.
we've been looking at OpenShell for the isolated environment and Bay to see what we'd still pick up running directly on the workstations. i'd start with a repo people already work on every day. that'll show pretty quickly where the sandbox gets in their way.
if you got this to stick, what did you have to fix before people stopped going back to their usual setup?

I got tired of dumping huge files into Claude/Cursor, hitting context limits early, and watching the model hallucinate edits across files it didn't actually understand.

So I built CodeGraphy:

- Parses your repo locally with Tree-sitter AST (100% offline, zero cloud indexing)

- Builds an interactive dependency graph and detects circular imports (Tarjan SCC)

- Compresses context by ~82.8% using Smart Context Builder before sending to an LLM

- Exposes 11 STDIO MCP tools directly to Claude Desktop, Cursor, and Windsurf

Open-source CLI/MCP core is on PyPI right now:

`pip install codegraphy-lite`

Would love brutal feedback on what breaks on your repos!

Pragtical v3.15.0 improves how the editor handles fonts, Unicode text and rendering, while making Settings easier to search and reset. It also adds workspace recovery checkpoints, more predictable line wrapping, richer clipboard support, and a native MSVC build for the Windows packages.

https://pragtical.dev/blog/pragtical-v3150-release

I've been building LampRabit, a free, MIT-licensed local dev environment in the spirit of Laragon and XAMPP. It runs on Windows, Linux and, as of 0.6.0, macOS (Apple silicon and Intel).

What it does for PHP work:

Every folder in www is served at https://<folder>.test with a trusted local certificate, and public/ is detected

Several PHP versions side by side, chosen per site. php and composer in the terminal follow the site's version

Apache, Nginx, Caddy or FrankenPHP per site; MariaDB, MySQL, PostgreSQL, Redis and others; phpMyAdmin, Adminer and Mailpit included

Templates for Laravel, Symfony, WordPress, Drupal, Statamic, Magento and more, asking the same questions their installers do

A project doctor that checks things like Laravel's app key, built assets and the storage link, and previews fixes before applying them

New in 0.6.0: a Dependencies tab showing Composer (and npm etc.) packages, required vs installed, with updates; every command is shown before it runs. Also npm now works behind HTTPS-inspecting corporate proxies.

It also does Node, Python, Go, Rust and Java, but PHP is where it started.

Built with Rust + Tauri + React. Repo and downloads: https://github.com/LampRabit/LampRabit

It's still early (0.x), so I'd really appreciate bug reports, especially from Mac users, and honest takes on what would make you switch from Herd, Laragon, DDEV or whatever you use now.

Hey everyone!

I've been experimenting a lot with AI coding agents like Claude Code and Codex, and one problem I kept running into was how difficult it is to coordinate agents when multiple developers are working on the same project.

Most agent tools are designed around a single developer. But when you're working in a team, things get complicated pretty quickly:

• Agents can modify files another developer is responsible for.

• Multiple agents can end up working on the same task.

• Frontend and backend agents can make conflicting assumptions about API contracts.

• Coordinating everything manually through Slack, tickets, or copy-pasted prompts gets tedious.

So I started building CodeRelay, an open-source tool built on top of T3 Code that focuses on collaboration between developers' coding agents.

The idea is pretty simple: each developer owns certain parts of a repository, and when an agent needs something outside its owner's scope, it can hand off that work to the appropriate teammate's agent.

How it works:

1. Developers join a shared Team Hub and declare which parts of the repository they own.

2. An agent can propose a task to another developer, including an API contract pinned to a specific Git commit.

3. The receiving developer reviews and accepts the task into their own agent thread.

4. Once the work is completed, the original developer gets the branch, commit, and summary to integrate.

The goal isn't to replace existing coding agents, but to make them work better together across a team while keeping developers in control.

There's also a local Alice/Bob demo you can run to test the entire handoff workflow without setting up a separate team.

The project is still early, and I'd genuinely appreciate feedback, especially from developers already using multiple coding agents in shared repositories.

GitHub: https://github.com/AymanAhsan/CodeRelay

Website: https://site-olive-two-79.vercel.app/

Site and docs: callgraph.eu

Repo and releases: github

We build pitwall at Quantic Studios. It’s a free, MIT-licensed terminal multiplexer for coding agents. v0.2.10 adds a downloadable Android companion for the agents running on your computers.

The phone shows sessions across paired machines, with agents waiting for you at the top. You can read conversations and tool output, send a message or image, and answer supported approval prompts. The agents keep running on the computers.

Some implementation details: the Android app uses Go and Gio. It talks to the same backend API as the phone web client. The desktop reads supported agents’ session files for conversation history, rather than sending a video of the terminal to the phone. Claude Code, Codex and pi transcripts are supported.

There’s no pitwall account or hosted relay. You connect over your own network using the documented Tailscale or SSH setup, then pair with a QR code. The phone service is off by default and listens on localhost when enabled.

The APK needs Android 9 or newer on arm64. It’s distributed through GitHub, not the Play Store. Update checks can download a newer APK, but Android still asks you to confirm installation. Coding-agent accounts and subscriptions are separate.

The screenshots show demo sessions on two machines and a conversation with tool output.

Release and source: https://github.com/quanticstudios/pitwall/releases/tag/v0.2.10

Phone setup: https://github.com/quanticstudios/pitwall/blob/v0.2.10/docs/phone.md

Please see my post on r/ExploitDev

Hey everyone!

I've been experimenting a lot with AI coding agents like Claude Code and Codex, and one problem I kept running into was how difficult it is to coordinate agents when multiple developers are working on the same project.

Most agent tools are designed around a single developer. But when you're working in a team, things get complicated pretty quickly:

• Agents can modify files another developer is responsible for.

• Multiple agents can end up working on the same task.

• Frontend and backend agents can make conflicting assumptions about API contracts.

• Coordinating everything manually through Slack, tickets, or copy-pasted prompts gets tedious.

So I started building CodeRelay, an open-source tool built on top of T3 Code that focuses on collaboration between developers' coding agents.

The idea is pretty simple: each developer owns certain parts of a repository, and when an agent needs something outside its owner's scope, it can hand off that work to the appropriate teammate's agent.

How it works:

1. Developers join a shared Team Hub and declare which parts of the repository they own.

2. An agent can propose a task to another developer, including an API contract pinned to a specific Git commit.

3. The receiving developer reviews and accepts the task into their own agent thread.

4. Once the work is completed, the original developer gets the branch, commit, and summary to integrate.

The goal isn't to replace existing coding agents, but to make them work better together across a team while keeping developers in control.

The project is still early, and I'd genuinely appreciate feedback, especially from developers already using multiple coding agents in shared repositories.

GitHub: https://github.com/AymanAhsan/CodeRelay

Website: https://site-olive-two-79.vercel.app/

Hey everyone!

I've been working on a project called Burnline, and I'm excited to finally share it with you all!

If you're someone who regularly uses Claude Code or OpenAI Codex, you've probably wondered how many tokens you've actually burned through, what all that usage would cost at API rates, or how much of your plan limits you have left.

That's exactly what Burnline is built for.

Burnline is a free, open-source, local-first macOS app that tracks your AI coding usage, gives you detailed insights, and makes the whole experience a little more fun with streaks, achievements, and milestones.

It lives right in your Mac's menu bar as a tiny flame that burns brighter the more you use your AI coding tools!

🔥 What can Burnline do?

• Token & cost tracking: See how many tokens you've consumed and what they would have cost at historical API prices. Break everything down by project, model, provider, session, or day, all the way back to your earliest recorded usage.

• Live plan limits: Track your Claude Code and Codex usage windows, see when they reset, and get warned if you're on pace to hit a limit before your window resets.

• Coding streaks & activity heatmaps: A GitHub-style heatmap of your AI coding activity, with daily streaks and a visual progression that evolves as you keep coding.

• 132 achievements to unlock: Earn medals for milestones, consistency, token usage, efficient caching, and more. Some reward productivity, while others reward efficiency!

• Usage insights & comparisons: Ever wondered what billions of tokens actually look like? Burnline puts your usage into perspective with some fun comparisons.

• Notifications & milestones: Get notified about approaching limits, usage thresholds, resets, and achievements.

• Historical analytics: Explore usage trends over time, see which projects consume the most tokens, and understand how much caching has saved you.

🔒 Privacy was a big priority

I wanted this to be something you could run without worrying about where your data goes.

• No accounts or sign-ups.

• No backend server storing your usage.

• No telemetry or analytics tracking you.

• Your usage data stays on your Mac.

• Burnline never reads or stores your prompts, responses, or source code.

It works with the local usage data that Claude Code and Codex already maintain. Network access is limited to things like fetching plan limits, checking for updates, and updating API pricing information.

💻 What's supported?

Currently, Burnline supports macOS 14+, with integrations for:

• Claude Code

• OpenAI Codex

I'm also planning support for OpenCode and Antigravity, along with more AI coding tools!

And for Windows users, a Windows version is coming soon! I want Windows users to be able to enjoy the same usage tracking, streaks, and achievements.

🚀 Download Burnline

Website: https://burnline-app.vercel.app

GitHub: https://github.com/igharsha7/Burnline-AI-Usage-Tracker

It's completely free and open source (AGPL-3.0). You can download it, explore the source, open issues, suggest features, or contribute!

This is just the beginning. I've got quite a few more features and improvements planned, and I'd love to keep making it better.

I'd genuinely love to hear your feedback! Whether it's a feature you'd like to see, something that could be improved, or even a bug you encounter, please let me know.

And if you find the project useful, giving the repository a ⭐ would mean a lot and help more developers discover it!

Thanks for taking the time to read through this. Hope some of you find Burnline useful! 🔥

Hey everyone,

I kept switching between 10+ websites to do simple things — format JSON, decode JWTs, convert images, test regex. So I built one site that has everything.

devtools-hub-mauve.vercel.app

26 tools across 9 categories:

• Developer: JSON Formatter, JWT Decoder, Regex Tester, UUID Generator, Hash Generator, Base64/URL Encode, SQL Formatter, CSV/JSON Converter

• Content: Hashtag Generator, YouTube Title Generator, Word Counter, Case Converter

• Design: Color Picker (with opacity), Box Shadow Generator, Favicon Generator, Image Converter, Social Media Image Resizer

• SEO: Meta Tag Generator

Key features:

• All processing happens client-side (your data never leaves the browser)

• Dark/light mode

• Works offline (PWA)

• No signup, no paywall

• Related tools navigation between pages

Built with Next.js 16, Tailwind CSS v4, deployed on Vercel.

Would love feedback — what tools should I add next? Thinking about a BG Remover and PNG-to-SVG converter.

The GitHub Copilot app is the only desktop experience for agent-driven development built natively on GitHub. Available for macOS, Windows, and Linux, on any Copilot plan, or bring your own key. https://github.com/features/copilot?mobile_download=true

When a client patch comes back from review, I’d write down three things before fixing it: the behavior that had already been agreed, the record that establishes it, and one check that would have caught the mismatch.

In a made-up example, an agent changes a webhook retry policy. Review turns up an earlier exception: retries stay off for a client whose receiver can’t deduplicate. The new default is fine for other clients. The useful record is the rollout note that says where the exception applies. The check is a retry test with the exempt client configuration alongside the default case.

I’d keep the source and the test next to the ticket. If the test is easy to add but finding the exception still means asking whoever was in the rollout meeting, that’s the part I’d measure on the next change.

I’m building Shifu and researching where this work still falls on developers. If you ship client software, on your last reworked change, where did you find the deciding evidence and which step still needed a person? I’d also like cases where the existing tooling found it early. A rough description without client names or code is enough.

Searching for imports of a module finds its direct consumers. A change can matter further up the dependency chain too.

I maintain ArchUnitTS. The graph API has a reverse view for that:

const report = projectGraph()
  .dependentsOf('src/server/store.ts');
await report.exportAsHTML('reports/store-consumers.html');

Import projectGraph from archunit and run this from an async function at the project root.

In a route → service → store fixture, the report included the route as well as the service. An unrelated file was left out. That gives you a focused list to inspect before changing a storage abstraction or moving a shared module.

This isn't a prediction that every listed file will break. It's the transitive dependency view of the imports the tool resolves. I find that distinction useful: use it to decide where to look, then use tests and review to judge the actual change.

Source: https://github.com/LukasNiessen/ArchUnitTS

One thing that's easy to overlook when using AI coding agents like Claude Code or Codex is how much access they can have to your local environment.

Your .env files, API keys, database credentials, and SSH keys might all be accessible.

We're working on Good Door, an open-source CLI that helps reduce that exposure.

Here's what it does:

• Encrypts sensitive files and credentials.

• Uses OS-backed secure storage, including macOS Keychain and Windows DPAPI.

• Lets commands access protected secrets when needed.

• Helps mask sensitive values in supported AI coding workflows.

• Works locally without requiring a separate cloud secrets manager.

It's not a complete sandbox, but the goal is to make managing secrets safer and easier for developers who use AI agents.

Would love some feedback from developers who use AI coding tools. How are you handling secrets in your workflows?

I've been experimenting with AI coding tools like Cursor and Claude Code, and one thing that kept bothering me was how difficult it is to get them to recreate an existing website's actual design.

You give an AI agent a reference website and ask it to build something similar, but it often ends up guessing:

• Colors are slightly off.

• Typography doesn't match.

• Spacing and border radii are inconsistent.

• The overall result looks like a generic AI-generated UI.

So I built styleprobe to solve this problem.

It's an open-source CLI that takes a website URL and extracts its visual design system.

A few things it can do:

• Extract colors and semantic design tokens.

• Analyze typography, spacing, shadows, and component styles.

• Crawl multiple pages instead of relying on just the homepage.

• Extract SVG logos and other brand assets.

• Export directly to Tailwind, shadcn/ui, Figma tokens, or AI-agent instruction files.

You can also try the web playground here:

https://styleprobe.vercel.app/

GitHub: https://github.com/spidervirus/styleprobe

It's MIT licensed and completely open source.

I'm still improving it, so I'd genuinely love feedback from developers:

1. Would something like this fit into your AI-assisted development workflow?

2. What other design information would you want it to extract?

3. What would make you actually use this regularly?

Would love to hear your thoughts!