标签：#productivity

After months of building in public, is live on Product Hunt today! 🎉 The problem Every dev team I've worked with ends up in the same trap: Jira is too heavy and slows everyone down with ceremony, while Trello/Notion are too light and can't actually tell you if your sprint is on track. Nobody had a tool that combined real project management with AI that actually understands developer workflows. So I built one. What is Rahnuma.io? Rahnuma.io is an AI-powered DevOps platform that sits where project management meets your actual engineering workflow: 🧠 AI task generation — describe a feature in plain English, get a structured task with subtasks 📊 Deadline risk forecasting — a live risk score (0–100) built from time risk, blockers, and completion rate, so you know a sprint is in trouble before it blows up 🗂️ Kanban + sprints — drag-and-drop boards, WIP limits, burndown charts, story points 🤖 AI sprint retros — auto-generated "what went well / what didn't / action items" 🔗 GitHub & Bitbucket integration — see commits next to the tasks they belong to 📈 Reports that don't require a translator — including an "Explain to My Boss" button that turns your sprint into a plain-English executive summary 🔔 Slack notifications for task creation, assignment, and comments 🧾 Client portals — shareable, printable progress reports for non-technical stakeholders Why it's different Most "AI project management" tools just bolt a chatbot onto a Trello clone. AI is wired directly into the data model — it knows your sprint history, your velocity, your blockers — so the forecasts and summaries are grounded in your actual project state, not a generic prompt. Tech under the hood Next.js 15 (Turbopack) · TypeScript · Prisma + PostgreSQL · Clerk auth · Polar billing · Redis · xAI Grok with Groq fallback for AI · Server-Sent Events for realtime sync. Try it It's free to start, no credit card required. I'd love your feedback — especially from anyone who's felt the Jira-is-too-much / Trello-is-too-littl

You use Claude Code, or ChatGPT, or both, every day. Quick question: how many messages did you send last month? Which model ate most of your budget? How much did prompt caching actually save you? You don't know. I didn't either. That's a weird gap. We instrument everything else — git activity, deploy frequency, test coverage — but the tool we now spend the most hours inside is a black box. The vendor dashboard, if it exists, is a billing page, not a mirror. So I built four tiny tools to fix that for myself. They all run 100% locally . No accounts, no API keys, no telemetry, no network calls. They read files that are already on your disk and print something you can look at. All four are open source on github.com/greymoth-jp — and because that's a real claim, the only thing I'll ask is that you grep the source yourself before you trust me. Here's the privacy point up front, because it's the whole design: these read your data, but your data never leaves your machine. That's not a feature I'm bolting on for a marketing line. It's the reason the tools are small enough to audit in one sitting. The one number that changed how I work Before the tools, here's what I assumed: my Claude Code bill is dominated by the prompts I write, so to spend less I should write tighter prompts. Compress the context. Trim the system message. The usual advice. I ran the numbers on my own ~/.claude transcripts and got this: component share of cost cacheRead 72% cacheWrite ~19% output the rest input ~0.3% Input — the thing everyone tells you to compress — was 0.3% of my spend. Compressing my prompts to save money would've been optimizing the rounding error. Worse: compressing a static prompt changes its bytes, which busts the prefix cache, which can make the bill go up . The real cost center was cache reads: long sessions dragging a fat context forward, turn after turn. That points at completely different levers — cache hygiene (milestone /compact , /clear before the context balloons, keeping C

I built a large feature. That's not what this is about. What changed is the baseline — the standards, docs, and automation that exist now and didn't two weeks ago. Everything after this will be built on top of it. Automated tests now ship with new features QA testers were testing. The product was covered. What didn't exist was automation — no E2E suite, no unit tests for new work, no repeatable spec. Now it does. The manual QA cycle stays. The automation catches what humans miss on the tenth pass. Quality leap going forward. Human hours saved. The next feature ships with both. The baseline is set Knowledge lives in the repo. Bug catalog with root causes — so the same thing doesn't get fixed twice. Tech debt inventory with a phased plan. Testing strategy documented, not assumed. GraphQL schema committed and validated against — drift gets caught before it ships. Pre-commit hooks that enforce the standards automatically. The frontend and backend documentation are cross-referenced as single sources of truth. The agent instructions point to the right places. Everything new builds on what's already written. Schema-first development The workflow is now: if the schema accommodates the new field, reuse what exists. If it doesn't, the schema update creates the new structure, the data migrates, and everything stays consistent. No guessing. No drift. One source of truth for what the data looks like. The feature is what you see. The baseline is what you don't — and it matters more.

Here's a thing that surprises people the first time: an email sent through the API does not carry the signature the user set up in Gmail or Outlook. Provider signatures live in the provider's compose UI, and a programmatic send bypasses that entirely, so a message your app sends goes out with no signature at all unless you add one. The Nylas Signatures API is how you add it: store an HTML signature once, then attach it to a send by ID, and the signature gets appended to the message for you. This post covers signatures from two angles: the HTTP API your backend calls, and the nylas CLI for creating and testing one from the terminal. I work on the CLI, so the terminal commands below are the ones I reach for when I'm setting a signature up. Nylas signatures are separate from provider signatures The first thing to get straight is that these are not the user's existing signature. Nylas doesn't sync the signature configured in Gmail, Outlook, or any other provider, and that provider signature is never applied to mail sent through the API. If a message your app sends needs a sign-off, you create that signature with this API and attach it explicitly; there's no inheriting it from the connected account. That separation is deliberate, because a programmatic send is a different context from a person typing in their webmail. It does mean the responsibility is yours: a user who connects their mailbox expecting their familiar signature to appear on app-sent mail won't get it automatically. Stored signatures are grant-scoped, living at /v3/grants/{grant_id}/signatures , so each connected account has its own set, and they're HTML, so a branded sign-off with a logo and links works the same as a plain one. Create a signature Creating a signature is a POST /v3/grants/{grant_id}/signatures with a name and an HTML body . The name is for you, a label to find it by later; the body is the markup that gets appended to outbound mail. The response returns the signature with its ID, which is w

Introduction I'm Ahmer. I'm 19, I'm doing a 4-year Software Engineering degree at a fairly...

Most people lose hours pretending to work or study. I was one of them. I kept setting Pomodoro timers and ending up scrolling Twitter during breaks. That's not rest. That's just a different kind of distraction. So I built Mognota — a free wellness companion for screen workers. The Problem You don't have a discipline problem. You have a system problem. Your brain has a hard biological limit. Sustained attention peaks at 20-45 minutes before quality drops sharply. Long unfocused hours are not work — they are the feeling of work. The solution isn't more willpower. It's intentional recovery. What I Built Mognota pairs a Pomodoro timer with 50+ guided wellness activities: 👁️ 20-20-20 eye break reminders 🫁 Guided breathing & 7 pranayama techniques 🧘 Desk yoga, HIIT, Tai Chi, stretches 🎵 Binaural beats & ambient soundscapes 🧠 Meditation & NSDR protocols 📓 Gratitude journal, mood tracker, brain dump 🎮 Sudoku, sliding puzzle, fractal explorer The Technical Part This is what dev.to might find interesting: Pure HTML, CSS, vanilla JS — zero frameworks Everything in a single HTML file All 8 notification sounds synthesized with Web Audio API localStorage only — nothing leaves your device Works offline once loaded 109+ languages supported No npm. No build step. No dependencies. Just open and use. Try It 👉 https://mognota.com/ Completely free. No account. No ads. Forever. Would love brutal honest feedback from this community.

Over the past weeks, I’ve been sharing a series of posts that gravitate around one question: How do...

I build Voxis, an open-source Windows app that translates whatever your system is playing — a video, a game, the other side of a call — and plays the translation back as spoken voice, a few seconds behind the speaker. No subtitles, no virtual audio cable, no bot joining your meeting. The "no virtual cable" part is the bit worth writing about. Almost every system-audio tool on Windows tells you to install VB-CABLE or VoiceMeeter, or to drop a bot into your call. Voxis doesn't, for incoming audio. This post is how that capture engine works, and the sharp edges I hit building it in Python. I'll be specific about what's hard and honest about what's not mine to fix. The goal Read the exact audio the user is hearing — the post-mix system output — at 16 kHz mono, and do it without installing anything. Then stream it to a translation model and play the result back, all while the original keeps playing underneath. Three constraints fall out of that: Driverless. If it needs a reboot and a driver, it's not zero-setup. No self-feedback. The app plays translated audio into the same system mix it's capturing . Naively, it would capture its own voice and translate the translation. That has to be impossible by construction, not patched with an echo gate. Realtime-safe. Capture can't stall. If the downstream VAD or garbage collector hiccups, the WASAPI ring buffer must not overflow. WASAPI process-loopback: capturing the mix, minus yourself Windows 10 version 2004 added the ApplicationLoopback API — a way to activate an IAudioClient in loopback mode scoped to a process tree, either including only that tree or excluding it. Excluding our own process tree is exactly what constraint #2 needs: the captured mix is everything the user hears, with Voxis's own output removed. You don't get this client from the normal IMMDeviceEnumerator path. You activate it by name through ActivateAudioInterfaceAsync , passing the loopback parameters in a PROPVARIANT carrying a BLOB : params = AUDIOCLIENT_

About a year ago, I turned my gaming PC into a local AI Lab. And yes, the most important word in that sentence is LOCAL . Let me tell you the story of how I sacrificed my gaming hours to build several tools, and now I'm going to tell you about this one that I use every single day. The Problem: Token bankruptcy Day to day, all of us developers who work with Artificial Intelligence share the same headache: tokens and rate limits . We're all victims of the high prices that come with constantly running inference with AI agents like Claude Code, Codex, or Gemini CLI (yeah, I love working from the terminal, I LOVE CLIs). While I was building AI systems (agent orchestration, LLM fine-tuning ), I was burning through way too many tokens. I tried tweaking the prompts and cleaning up the junk in my context, but the real devourer of my quota showed up when I had to learn a new tool. I was implementing solutions in QGIS (QGIS is a free, open-source Geographic Information System (GIS) software that allows users to create, edit, visualize, analyze, and publish geospatial data on maps) for a project and I didn't know the interface 100%. Like any dev facing something new, I leaned on AI agents: I'd take a screenshot, send it over, and ask for explanations. Here's an important fact that hurt my wallet: A screenshot on my MacBook (Full HD resolution of 1920x1080) burns about 258 tokens per tile on models like Claude. That adds up to roughly 1,548 tokens per image (sounds like a lot, and yeah my friend, it is way too much when we're talking about context). Now imagine sending dozens of these images a month trying to understand a complex interface as a 2x dev (99x, I'd say, in this new AI era). I was eating through my hourly Claude allowance just doing visual queries, leaving me with no quota left to generate the actual code I really needed for my development. The Epiphany (and the Hardware) One day, during a forced break thanks to a Claude rate limit , I looked over at my Gaming PC. I

Claude Code is a genuinely powerful CLI coding agent. Its context window handling and multi-file reasoning set a high bar in 2026. But it comes with real constraints - it requires an Anthropic API key, charges per token, locks you into Claude models only, and its source code is closed. For developers running local-first workflows, working in air-gapped environments, or simply preferring auditable tooling, those limitations are dealbreakers. The good news: the open-source ecosystem has matured significantly. Nine production-ready alternatives now cover every major workflow pattern - from terminal-first pair programming to fully autonomous task execution. Why Open Source Matters for AI Coding Agents AI coding agents operate at a high level of system trust. They write files, run commands, and modify your repository. That makes transparency genuinely important - not just philosophically. Open-source licensing lets you read the code, audit its behavior, self-host without sending data to a third party, and customize it for your team's needs. Beyond trust, the practical advantages are real. Open-source agents are model-agnostic by design. They connect to whichever LLM you prefer - Claude, GPT, Gemini, DeepSeek, or a local model via Ollama - letting you optimize for cost and capability on a per-task basis rather than being locked to one pricing tier. OpenCode - The Closest Open-Source Drop-In for Claude Code OpenCode has emerged as the de facto open-source answer to Claude Code in 2026, crossing 161,000 GitHub stars under an MIT license. It connects to over 75 LLM providers via Models.dev - including local Ollama models - and lets you switch providers mid-session. Internally it uses a dual-agent architecture: a Plan agent handles task decomposition while a Build agent executes changes. LSP integration brings symbol resolution into the terminal. Multi-session support lets you run parallel agents on the same project simultaneously. OpenAI Codex CLI - Auditable and Sandbox-Fir

Sometimes, the best ideas come when you least expect them — like at 2 AM, scrolling through social media with nothing exciting to do. That’s exactly how IGram, my latest side project, came to life. No grand plans, no investors, no pressure — just a spark of curiosity and a desire to build something fun. In this post, I’ll share the story of how IGram started, what it is, the challenges I faced, and what I learned along the way. If you’ve ever wondered what it’s like to build a messaging app from scratch or are just curious about side projects, this one’s for you. HOW IT BEGAN _**A few days ago, stuck in an endless social media scroll loop, I suddenly thought, “Why not build my own messaging app?” Not to compete with the giants like Telegram or WhatsApp, and certainly not because I had a startup idea or funding. Simply because I wanted to see how far I could take it. That spontaneous idea turned into IGram, a project born purely out of boredom and a hunger to learn. What Is IGram? IGram is a modern messaging app inspired by platforms like Telegram and Discord. But it’s not a clone. Instead, it’s designed to feel fast, smooth, and enjoyable—an experience I wanted to craft from the ground up. It’s my personal challenge and learning experiment, built solo and fueled by the excitement of creating something new. Features You’ll Find in IGram Even though it started as a simple idea, IGram has grown to include a solid set of features: One-to-one messaging Group conversations Channel support Message reactions, editing, and deletion Reply and message forwarding Search functionality Dark and light themes Responsive design and mobile-friendly layout User profiles and modern UI animations Every feature is designed to keep the app feeling smooth and responsive, because the user experience matters just as much as the functionality. The Biggest Challenge: User Experience Surprisingly, writing the code wasn’t the toughest part—it was designing how everything flows and feels. Modern

Introduction Most developers today are learning how to “use AI APIs.” But that’s not enough anymore. The real shift happening in software engineering is this: We are moving from building APIs → to building AI-powered systems. And that requires a completely different mindset. The Problem with Most AI Tutorials Most tutorials show this: Call OpenAI API Get response Print output That’s it. But in production systems, this approach fails because it ignores: Context management State handling Reliability Tool integration System design In real applications, AI is not a function call — it is an orchestrated system. What an AI System Actually Looks Like A production AI system usually includes: 1. Input Layer Validation Preprocessing Safety checks 2. Reasoning Layer (LLM) Prompt engineering Context injection Model selection 3. Tool Layer APIs Databases Search engines Internal services 4. Memory Layer Conversation history Vector DB / embeddings User context 5. Output Layer Formatting Validation Response filtering Simple Example: From API Call → AI Agent Thinking Instead of this: response = client . chat . completions . create (...) We design something like this: class AIAgent : def __init__ ( self , llm , tools ): self . llm = llm self . tools = tools def run ( self , user_input : str ): context = self . build_context ( user_input ) response = self . llm . chat . completions . create ( model = " gpt-4o-mini " , messages = context , temperature = 0.2 ) return self . post_process ( response ) Now AI becomes: ✔ structured ✔ extendable ✔ production-ready Key Shift in Thinking Old mindset: “How do I call the model?” New mindset: “How do I design the system around the model?” That’s the difference between: ❌ AI script ✅ AI product system Why Tools Matter More Than Prompts Modern AI systems are not just text generators. They are tool-using systems . Examples: Search APIs (RAG systems) Databases (SQL, NoSQL) External APIs Internal business logic This turns AI from “chatbot” into “agent

If you've ever watched a hacker movie and seen someone plug in a USB and own a machine in seconds — that's not Hollywood magic. That's a Rubber Ducky. And I built one for under ₹150. Here's exactly how I did it, what it taught me, and why every security student should build one. What Even Is a Rubber Ducky? A Rubber Ducky is a USB device that pretends to be a keyboard. The moment you plug it in, the operating system trusts it completely — because keyboards don't need driver approvals or admin permissions. Once trusted, it starts "typing" pre-programmed commands at superhuman speed. We're talking 1000 keystrokes per second. By the time you blink, it's already opened PowerShell, run a script, and closed the window. The original Hak5 Rubber Ducky costs around $80. I built mine for ₹150. What I Used DigiSpark ATtiny85 — ₹120–150 on Amazon India Arduino IDE — free A Windows test machine (my own laptop) 15 minutes That's it. No soldering. No special skills. Just a tiny microcontroller the size of a thumb. Setting It Up Step 1 — Install Arduino IDE Download from arduino.cc and install normally. Step 2 — Add DigiSpark Board Support Go to File → Preferences and paste this into Additional Board Manager URLs: http://digistump.com/package_digistump_index.json Then go to Tools → Board → Board Manager, search Digistump and install. Step 3 — Install Drivers DigiSpark needs Micronucleus drivers on Windows. Download from the official Digistump GitHub and run the installer. Step 4 — Write Your First Payload This opens Notepad and types a message — my first ever "attack": cpp#include "DigiKeyboard.h" void setup() { DigiKeyboard.delay(2000); DigiKeyboard.sendKeyStroke(KEY_R, MOD_GUI_LEFT); // Win+R DigiKeyboard.delay(500); DigiKeyboard.print("notepad"); DigiKeyboard.sendKeyStroke(KEY_ENTER); DigiKeyboard.delay(1000); DigiKeyboard.print("Hello. Your keyboard is now mine."); } void loop() {} Upload it, plug in the DigiSpark, and watch it type on its own. That moment hits different when y

Hey dev community! 👋 As developers, our inboxes often turn into a graveyard of job alerts (LinkedIn, Indeed, ZipRecruiter) and tech newsletters we subscribe to with the intention of "reading later" but never actually open. The result? Important emails get lost, and we get the dreaded "Account storage is almost full" notification. Recently, I hit that wall. I had thousands of accumulated emails. While Gmail allows you to create filters for incoming mail, it doesn't have a native feature to say: "Delete this email automatically after 7 days" . So, I decided to solve it the way we solve everything: by writing some code. 🛠️ The Solution: Google Apps Script + JavaScript Since the Google Workspace ecosystem runs on a JavaScript-based environment, I put together a custom script. Fun fact: a simple loop originally failed due to Google's strict 6-minute execution limit. To fix this, I optimized the code to process emails in batches of 100 , preventing the server from timing out. Here is the final production-ready script: function cleanSpamTsunami() { // 1. Loop to delete ALL Job Board emails in batches of 100 var continueJobSearch = true; while (continueJobSearch) { var jobThreads = GmailApp.search('computrabajo OR indeed OR linkedin OR OCC OR neuvoo OR talent.com OR jooble', 0, 100); if (jobThreads.length > 0) { Logger.log('Deleting a batch of ' + jobThreads.length + ' job alert emails...'); GmailApp.moveThreadsToTrash(jobThreads); } else { Logger.log('No more job alerts found!'); continueJobSearch = false; // Break the loop } } // 2. Loop to delete old Newsletters (older than 7 days) in batches of 100 var continueNewsletters = true; while (continueNewsletters) { var newsletterThreads = GmailApp.search('unsubscribe OR "cancelar suscripción" older_than:7d', 0, 100); if (newsletterThreads.length > 0) { Logger.log('Deleting a batch of ' + newsletterThreads.length + ' old newsletters...'); GmailApp.moveThreadsToTrash(newsletterThreads); } else { Logger.log('No more old newslett

Table of Contents The Moment That Changed Everything What It Actually Is The Setup Nobody Believes Is This Simple Focused Sessions — One Agent, One Mission Sub-Agents With Specific Skill Sets Building MCPs for Your Own Stack What We've Actually Achieved How It Became a Force Multiplier for Incident Response From OpenCode to FRIDAY — The Agent That Investigates Incidents Autonomously From FRIDAY to JARVIS — Thinking About Write-Path Autonomy Deleting 130,000 Accounts Without Writing Code Learning the Entire Product in Conversations Why This Is Different From ChatGPT The Uncomfortable Truth What's Next The Moment That Changed Everything It was 11pm on a Tuesday. A cache migration in our production environment had just caused thousands of authentication failures for two of our largest enterprise customers. Our VP of Product wanted answers. Our support team was fielding escalations. And our engineers were alt-tabbing between AWS console, Datadog, GitHub, Azure DevOps, and PagerDuty trying to piece together what happened. Three weeks later, when we needed to attempt the same change again, an engineer typed this into a terminal: "Review the ADO change ticket, compare the MOP against the actual ElastiCache configuration in prod region, check the K8s config repo for how Redis env vars are wired on the Green cluster, and tell me if this approach avoids the token validation failure that caused the previous customer impact." Fourteen seconds later , the system had pulled the work item, queried AWS ElastiCache across four regions, read the Kubernetes configuration from GitHub, cross-referenced the deployment patches, and delivered a precise technical assessment including a risk it identified that the team hadn't documented: in-flight tokens during the 30–60 second Global Accelerator propagation window. That system is OpenCode — an AI-powered CLI assistant connected to our entire operational stack through the MC(Model Context Protocol). And it has fundamentally changed how a 20-

Every serious AI workflow eventually runs into the same failure. The agent does useful work in one session. It learns the shape of the project. It figures out which assumptions were wrong. It follows a correction, makes a decision, and gets closer to the real work. Then the session changes. The next run starts too cold. Old context comes back without the correction that changed it. The agent asks for the same setup again. It repeats an assumption that was already fixed yesterday. You end up managing the memory of the work instead of moving the work forward. That is the problem Pith is built for. Pith gives AI agents durable project memory they can trust when facts change. It is not trying to make an agent remember everything. That would be the wrong goal. Real projects are messy. Facts change. Decisions get reversed. A note that was useful last week can become stale after a release, a migration, a new customer constraint, or one correction from the human operator. The harder problem is not recall. The harder problem is knowing which memory is still useful. Why Longer Context Is Not Enough Longer context helps, but it does not solve continuity by itself. A long prompt can carry more text into a single run. It cannot automatically decide which prior facts survived a correction, which decision is now superseded, or which evidence should come back when the project resumes three days later. Developers working with agents already feel this. The friction shows up as small taxes: repeating project background that the agent should already know; re-explaining decisions that were already made; correcting stale assumptions that were already corrected; losing the reason behind a prior choice; restarting from a cold state after every meaningful break. Those taxes compound. The more serious the workflow, the more expensive the memory gap becomes. If an agent is helping with a toy task, forgetting is annoying. If an agent is helping with a codebase, a release, a customer workflow,

Technology companies are extending AI beyond code generation into earlier stages of the software lifecycle, including PRD validation, design inputs, and code review. Initiatives from Uber, DoorDash, and Cloudflare highlight a shift toward AI-driven governance layers that evaluate engineering artifacts before implementation while preserving human oversight across the development pipeline. By Leela Kumili

Quando comecei a trabalhar com tecnologia, há mais de duas décadas, a Inteligência Artificial era algo restrito a laboratórios de pesquisa e ficção científica. Hoje, ela está embutida no aplicativo que recomenda sua próxima série, no e-mail que filtra spam automaticamente e até no GPS que recalcula sua rota em tempo real. A IA deixou de ser promessa para se tornar infraestrutura invisível do cotidiano. Neste artigo, quero ir além do hype e mostrar, com exemplos concretos, como essa tecnologia já transforma a forma como vivemos e trabalhamos. Produtividade pessoal e profissional turbinada O caso de uso mais palpável da IA hoje está na produtividade. Assistentes baseados em modelos de linguagem (LLMs) como ChatGPT, Claude e Gemini reduziram drasticamente o tempo gasto em tarefas que antes consumiam horas: redação de e-mails, geração de relatórios, resumos de reuniões e até depuração de código. Na minha rotina como gestor de TI, integrei essas ferramentas a fluxos de trabalho reais. Por exemplo, utilizo modelos de IA para revisar contratos de smart contracts escritos em Rust para a rede Stellar, identificando padrões de vulnerabilidade antes mesmo da auditoria formal. Não substitui a perícia humana, mas funciona como uma primeira camada de triagem que economiza tempo precioso da equipe. Algumas aplicações práticas que recomendo testar: Transcrição e resumo automático de reuniões com ferramentas como Otter.ai ou Fireflies Geração de documentação técnica a partir de comentários de código Automação de respostas em suporte de primeiro nível via chatbots treinados com a base de conhecimento da empresa O segredo está em tratar a IA como copiloto, nunca como piloto automático. A revisão humana continua indispensável, especialmente em contextos críticos. Saúde, finanças e decisões do dia a dia A IA também opera nos bastidores de decisões que afetam diretamente nossa qualidade de vida. No setor de saúde, algoritmos de visão computacional já auxiliam radiologistas na detecção pr

You have an API response. You want a Zod schema. So you paste the JSON into a JSON-to-Zod converter, copy the output, and ship it. Here's the trap: a lot of those converters infer basic types only . Your email , your uuid , your url , your ISO timestamp — they all come out as z.string() . The schema compiles, the types look right, and your validator quietly accepts "not-an-email" , "ftp://nope" , and "2026-99-99" forever. I wanted to see exactly how much gets lost, so I ran the same payload through two tools and diffed the output. Everything below is real, copy-pasteable output — nothing edited. The input A pretty ordinary user object: { "id" : "3f2a9c1e-5b7d-4e8a-9f1c-2d3e4f5a6b7c" , "email" : "ada@example.com" , "website" : "https://ada.dev" , "age" : 34 , "rating" : 4.7 , "created_at" : "2026-03-04T10:15:30Z" , "is_active" : true , "address" : { "city" : "Lyon" , "zip" : "69001" }, "tags" : [ "early-adopter" , "beta" ] } Tool 1 — json-to-zod (npm) const user = z . object ({ id : z . string (), email : z . string (), website : z . string (), age : z . number (), rating : z . number (), created_at : z . string (), is_active : z . boolean (), address : z . object ({ city : z . string (), zip : z . string () }), tags : z . array ( z . string ()), }); Structurally correct. But every meaningful field is a bare z.string() / z.number() . This schema will happily validate email: "lol" and created_at: "yesterday" . Tool 2 — TypeMorph import { z } from " zod " ; export const userAddressSchema = z . object ({ city : z . string (), zip : z . string (). regex ( /^ [ A-Z0-9 ][ A-Z0-9 \s\-]{1,8}[ A-Z0-9 ] $/i ), }); export type UserAddress = z . infer < typeof userAddressSchema > ; export const userSchema = z . object ({ id : z . uuid (), email : z . email (), website : z . url (), age : z . number (). int (). min ( 0 ). max ( 150 ), rating : z . number (). min ( 0 ). max ( 5 ), created_at : z . iso . datetime (), is_active : z . boolean (), address : userAddressSchema , tags :

Você já fez um commit no repositório do trabalho e percebeu que estava com o seu e-mail pessoal? Ou o contrário? Esse é um dos erros mais comuns de quem usa Git com múltiplas contas no mesmo computador. Neste tutorial você vai aprender a configurar tudo corretamente, de uma vez, usando chaves SSH separadas e .gitconfig condicional — sem gambiarras. O problema Por padrão o Git usa uma configuração global: git config --global user.name "Seu Nome" git config --global user.email "seu@email.com" Isso significa que todos os repositórios no seu computador usam o mesmo usuário. Quando você tem contas separadas (ex: joao@empresa.com no GitLab da empresa e joao@gmail.com no GitLab pessoal), os commits vão sair com o e-mail errado. A solução profissional envolve duas partes: Chaves SSH separadas para cada conta .gitconfig condicional que aplica o usuário certo — e a chave SSH certa — por pasta Passo 1 — Gerar as chaves SSH Abra o terminal e gere uma chave para cada conta. Use nomes diferentes para não sobrescrever: # Chave para a conta pessoal ssh-keygen -t ed25519 -C "joao@gmail.com" -f ~/.ssh/id_ed25519_pessoal # Chave para a conta do trabalho ssh-keygen -t ed25519 -C "joao@empresa.com" -f ~/.ssh/id_ed25519_trabalho 💡 Por que ed25519 ? É o algoritmo mais moderno, mais seguro e recomendado pelo GitHub, GitLab e Bitbucket. Evite RSA a menos que seu servidor seja muito antigo. Ao final você terá quatro arquivos em ~/.ssh/ : id_ed25519_pessoal ← chave privada (nunca compartilhe) id_ed25519_pessoal.pub ← chave pública (você registra no GitLab) id_ed25519_trabalho id_ed25519_trabalho.pub Passo 2 — Registrar as chaves no GitLab Para cada conta: Copie o conteúdo da chave pública: # Pessoal cat ~/.ssh/id_ed25519_pessoal.pub # Trabalho cat ~/.ssh/id_ed25519_trabalho.pub Acesse Settings → SSH and GPG keys → New SSH key na conta correspondente e cole o conteúdo. Faça isso nas duas contas , cada uma com a sua respectiva chave pública. Passo 3 — Configurar o Git por pasta (o pulo do gato)