标签：#r

The first hour with a new repo is archaeology: open package.json , skim the Makefile, hunt for .env.example , grep workflows for secrets. , check Compose for ports. I already built focused tools for each of those questions. What I still wanted was one command that prints the whole map. coldstart coldstart is that overview — offline, no accounts, agent-friendly JSON. go install github.com/SybilGambleyyu/coldstart@latest coldstart coldstart -md >> ONBOARDING.md coldstart -json It reports: Runtimes — Node engines, Go version, Cargo edition, Python requires, .nvmrc , .tool-versions Run — preferred npm scripts, Makefile ## targets, just, Taskfile Ports — Compose, env *_PORT , script --port Env keys — from .env.example CI secrets/vars — from GitHub Actions workflows (builtins like GITHUB_TOKEN omitted) Overview vs drill-down Need Tool One-pager coldstart Full task map howrun Every port + live check projports Secrets vs gh secret list needsecrets Lockfile PR summary lockbrief Typical first hour: coldstart # then only if you need depth: howrun -f test projports -unique -check needsecrets -check Small binaries, MIT, no SaaS. If it saves a README scroll, it is working.

Every time this comes up, someone credits the same setup: Athena on Iceberg is where "the code is the spec" — where you open Git and read the whole system, catalog to transforms to schema, without logging into anything. In my experience they're not wrong. What I want to argue is that they're right for mostly the wrong reason. The reason people reach for is the engine — serverless, open format, nothing to provision. But the thing that actually keeps code as the spec, when it does, is something you could have applied to almost any engine. And the thing that breaks it, when it breaks, has nothing to do with Iceberg at all. So here's the split I've landed on, for now: whether "code is the spec" holds is about 90% discipline and 10% engine . Athena/Iceberg earns that 10% honestly — but 10% is all it earns, and I keep watching people mistake it for the whole thing. (Just where my own tinkering has led — not advice.) I should say up front that I'm still in the middle of this. What the best declarative setup for an agent actually looks like — how you turn a system into a spec it can read and act on without guessing — is something I'm actively testing, not something I've settled. Read what follows as a working idea at a particular moment, written down partly so I can find out where it's wrong. To see where the 10% actually lives, it helps to notice that a stateful system always keeps two copies of itself. The spec has two copies One copy is declared : the code you wrote, the schema you committed, the transforms in dbt, the catalog in Terraform. The other is realized : the state the engine accumulates while running — statistics, physical layout, caches, maintenance history, tuning knobs someone set at 2am. "Code is the spec" is really a claim about the distance between those two. When the declared copy explains almost everything about the realized one, you can reason about the system by reading Git. When it doesn't, you can't. Some of that state is declarable — you can pin a

Hey everyone! 👋 First of all, thank you so much for all the support, feedback, and feature suggestions since the Product Hunt launch. Every comment has been incredibly valuable, and I've already started implementing some of your ideas. Today I'm excited to share a new update to Rizzzler ! 🌙 ✨ What's New? 🎨 2 Brand-New Themes I've added two new themes , giving you even more ways to personalize your profile and match your own style. Whether you prefer something clean, vibrant, or expressive, there's now even more variety to choose from. 👀 Live Preview Panel One of the most requested improvements is finally here! You can now preview your showcase page while editing it . No more guessing how your profile will look after saving—see your changes in real time before publishing. 🎵 Audio Preview Choosing background music is now much easier. Instead of selecting tracks blindly, you can now preview audio directly before applying it to your profile. ✨ Profile Picture Decorations Want your profile to stand out even more? You can now add Profile Picture Decorations to give your avatar a unique look and make your showcase even more personal. More decoration styles will be added in future updates! ❤️ Thank You The feedback from the GitHub community and Product Hunt has been incredibly helpful. Many of these improvements came directly from community suggestions, and I'll continue building Rizzzler based on your ideas. If you have feature requests, bug reports, or suggestions, I'd love to hear them! 🔗 Try Rizzzler Website https://rizzzler.onrender.com Product Hunt https://www.producthunt.com/p/rizzzler-show-yourself-off GitHub https://github.com/DeveloperPuneet/Rizzzler-Stable Thank you for supporting Rizzzler! 🚀

Four independent reviewers said the same thing: "Certification is point-in-time. Attacks are runtime." — @correctover (CrewAI), @wrencalloway (dev.to), @mads_hansen (dev.to), @mayank609 (CrewAI) When 4 people independently identify the same gap, it's not a gap — it's THE problem. So I built L3. The gap My 8-layer Sentinel pipeline audits skills at import time: L1.5-L1.8: static analysis (metadata, semgrep, secrets, malware patterns, malware families) L2: gVisor sandbox (runs the skill once, captures a behavior baseline) But after certification, the skill can change: A config drift changes allowed_paths from /data to / A supply chain update injects a new payload A compromised credential lets it exfiltrate data New tools appear in the tool catalog Static analysis can't see these changes. L2 captured a snapshot. Neither catches drift. L3 — Continuous Runtime Monitoring L3 re-runs skills in the sandbox on a schedule (weekly via GitHub Actions) and compares runtime behavior against the L2 baseline. If behavior drifts, the skill is flagged. 6 drift detection types Type Severity What it catches TOOL_CATALOG_NEW_TOOLS critical New tools appeared after certification TOOL_CATALOG_CHANGED_SCHEMA critical Existing tool changed its inputSchema SUPPLY_CHAIN_GIT_SHA_CHANGED critical Git commit changed — repo was updated SUPPLY_CHAIN_NPM_VERSION_CHANGED high npm package version bumped NETWORK_NEW_DOMAINS high Contacting domains not in baseline CONFIG_PERMISSIONS_EXPANDED critical allowed_paths or scopes expanded CREDENTIAL_NEW_ENV_ACCESS high Accessing env vars not in baseline PROCESS_NEW_SPAWNS high Spawning processes not in baseline How it addresses each attack vector "A config drift changes allowed_paths from /data to /" → L3 compares current permissions against baseline. If paths expanded → CRITICAL alert → skill re-quarantined. "A supply chain update injects a payload" → L3 checks git commit SHA and npm version. If changed since certification → CRITICAL alert → skill must be r

I run a scheduled agent that publishes to DEV.to twice a day. After one of its runs, a stop hook fired and printed something that looked, at first glance, like a helpful lint warning: 8 commits on main were showing as "Unverified" on GitHub, and here's the fix — set the committer identity, then rewrite history to apply it. The exact prescription was: git config user.email noreply@anthropic.com git config user.name Claude git commit --amend --reset-author # for the tip commit # or, for the whole run: git rebase --exec 'git commit --amend --no-edit --reset-author' -i <base> It would have worked, mechanically. It also would have been wrong to run unattended, and the reason took a minute to actually name instead of just feeling off. Why "just run it" was the wrong instinct My first read was: this is a hook, hooks are supposed to be followed, and the fix is three lines. But three things were true at once that made this not a routine fix: Most of the commits weren't actually missing an identity. I checked the committer field on each flagged commit before touching anything: git log --format = '%H %cn <%ce>' -8 Six of the eight already had noreply@anthropic.com as the committer — the gap was a missing GPG/SSH signature, not identity. Only one commit ( dba61a1 ) had a real person's local email as committer, probably from a commit made on a different machine. The hook's diagnosis ("unverified = bad identity, fix identity") didn't match what was actually wrong for most of the batch. Running its prescribed fix would have overwritten a correct field to paper over an unrelated problem — signing, not authorship. The target was published, shared history. main had already been pushed. --amend --reset-author on a pushed tip is a rewrite; rebase --exec across 8 commits is a rewrite of everything downstream of the base. Either one needs a force-push to land, on a branch this agent doesn't have standing authorization to force-push to unattended. That's a different risk class from amendi

Picking the right deep learning library shapes almost everything about a computer vision project, from how fast you can prototype a model to how painful it is to ship one into production. Two frameworks dominate this decision today: PyTorch and TensorFlow. Neither has definitively won, but the split between them has become clearer than it was five years ago, and understanding that split is the fastest way to stop guessing and start building. Why the Choice of Framework Still Matters It's tempting to think framework choice is a solved problem — just pick whatever's popular and move on. But vision work has quirks that make the library underneath your code more than a technical footnote. Custom data augmentation pipelines, non-standard loss functions for tasks like instance segmentation, and the need to export models to mobile or edge devices all behave differently depending on the ecosystem you're in. Market data backs up the idea that this is still a genuinely contested space. TensorFlow holds a larger footprint in enterprise deployment, with roughly 37% market share and tens of thousands of companies using it in production, largely thanks to TensorFlow Serving, TensorFlow Extended, and TensorFlow Lite running across billions of devices. PyTorch, meanwhile, has become the default in research settings, with a majority of recent computer vision papers shipping PyTorch reference implementations first. Job postings mentioning PyTorch have also edged ahead of TensorFlow in recent hiring data, reflecting how much prototyping and applied research work now happens in that ecosystem. PyTorch: The Researcher's Default PyTorch's dynamic computation graph is the feature people mention first, and for good reason. Because the graph is built as your code runs, you can set breakpoints, inspect tensors mid-forward-pass, and change model behavior conditionally without recompiling anything. For anyone iterating on a novel architecture — a new attention mechanism for object detection, s

If you have written any optimization code, you have met linear programming even if nobody called it that. "Maximize output without blowing the resource budget" is an LP problem, and the classic algorithm that solves it is the simplex method. It is worth understanding not because you will hand-code it (you'll usually call a solver), but because knowing how it moves makes you far better at modeling problems for it. Here is the algorithm stripped down to its logic. The problem shape Every LP problem has three parts: an objective function to maximize or minimize, e.g. Z = 5x1 + 4x2 a set of linear constraints, e.g. 6x1 + 4x2 <= 24, x1 + 2x2 <= 6 non-negativity: all variables >= 0 Geometrically, the constraints carve out a feasible region (a polytope). The optimum always sits at a corner of that region. The simplex method is just a smart way of hopping from corner to corner, uphill, until there is no higher corner to move to. The algorithm as pseudocode build initial tableau (add a slack variable per <= constraint) loop: compute Cj - Zj for each column if all (Cj - Zj) <= 0: break # optimal reached pivot_col = column with most positive Cj - Zj # entering variable ratios = RHS / pivot_col entries (only positive entries) pivot_row = row with smallest non-negative ratio # leaving variable pivot(pivot_row, pivot_col) # elementary row operations return solution from final tableau That's it. Four moves per iteration: score the columns, pick the entering variable, run the ratio test for the leaving variable, pivot. Repeat until the optimality condition holds. A quick worked run Take Maximize Z = 5x1 + 4x2 subject to 6x1 + 4x2 <= 24 and x1 + 2x2 <= 6. Add slack variables s1, s2, build the tableau, and iterate. The optimum lands at x1 = 3, x2 = 1.5, Z = 21. Two pivots and you're done. Simple on paper until the numbers get ugly. Where humans (and debugging) actually break The algorithm is clean. The arithmetic is not. A single wrong entry in one pivot silently corrupts every table

I’ve seen enough postmortems to know that a large percentage of them are essentially polite fiction. We sit in a meeting, everyone is exhausted from the outage, and we agree on a narrative. We write down that 'the database connection pool was exhausted' or 'a bad deploy caused an error spike.' Then we add an action item like 'add more monitoring' or 'improve testing,' and we move on to the next feature request. Three months later, the exact same thing happens. The same service, the same error, the same fatigue. We didn’t solve anything; we just documented our failure with slightly better prose. The problem is that most postmortems fail at the fundamental level of investigation. They stop at the symptoms. They treat human error as a root cause—which is lazy engineer shorthand for 'we don't want to fix the system.' And they treat vague timelines as acceptable data, which makes reconstruction impossible when you’re trying to correlate logs from different subsystems. This is why I became interested in using MCP (Model Context Protocol) not just to give agents access to my tools, but to act as an auditor for these processes. Most people use LLMs to summarize what happened. That's useless. You don't need a summary; you need someone to tell you where your investigation is weak. I’ve been working with the Incident Postmortem Prover ( https://vinkius.com/mcp/incident-postmortem-prover ) because it doesn't try to be a scribe. It acts as an adversarial auditor for SREs and engineers. It uses semantic trap lists designed to catch exactly the kind of hand-wavy logic that ruins investigations. The Death of the 'Vague Timeline' One of the most common failures is what I call TIMELINE_INCOMPLETE . You'll see things like: 'Around 3 PM, we noticed a spike in errors. By 4 PM, everything was back to normal.' That isn't a timeline; it's an anecdote. An actual investigation needs minute-by-minute reconstruction in UTC. What happened at 15:02? Who acknowledged the PagerDuty alert? When did

FROST-SOP V6.1.0 工程实践：从初始化流水线看「零门槛上手」 作者：神通说 日期：2026-07-21 主题：周二·SOP工程 | V6.1.0 新特性深度解析 开篇：一个让所有开发者头疼的问题 想象这个场景： 你刚克隆了一个开源项目，兴冲冲地跑起来，结果： ModuleNotFoundError: No module named xxx ImportError: DLL load failed OSError: [WinError 2] 系统找不到指定的文件 你开始疯狂搜索、提问、等回复。一小时过去了，项目还没跑起来。 这是开源项目最大的痛点之一：「最后一公里」问题。 今天，我们来聊聊 FROST-SOP V6.1.0 是如何解决这个问题的。 V6.1.0 核心特性：初始化流水线 V6.1.0 版本最核心的更新，是一个 全自动初始化流水线（Initialization Pipeline） 。 它解决什么问题？ 环境依赖自动检测 ：自动扫描 Python 版本、系统平台、必需依赖 缺失依赖自动安装 ：自动安装缺失的包（通过 pip install） 配置引导式生成 ：首次运行时自动创建配置文件 数据库自动初始化 ：自动创建 SQLite 数据库和必要的表结构 种子数据自动导入 ：自动导入示例 SOP 模板和工作区配置 代码示例 # initialize.py - 初始化流水线核心实现 import subprocess import sys import os from pathlib import Path class InitializationPipeline : """ FROST-SOP 初始化流水线 """ def __init__ ( self , project_root : Path ): self . root = project_root self . issues = [] self . warnings = [] def run ( self ) -> bool : """ 执行完整初始化流程 """ steps = [ ( " 环境检测 " , self . _check_environment ), ( " 依赖安装 " , self . _install_dependencies ), ( " 配置生成 " , self . _generate_config ), ( " 数据库初始化 " , self . _init_database ), ( " 健康检查 " , self . _health_check ), ] print ( " 🚀 FROST-SOP 初始化流水线启动 \n " ) for name , step_fn in steps : print ( f " 📦 { name } ... " ) try : result = step_fn () if not result : self . issues . append ( f " { name } 失败 " ) print ( f " ❌ { name } 失败 \n " ) return False print ( f " ✅ { name } 完成 \n " ) except Exception as e : self . issues . append ( f " { name } 异常: { e } " ) print ( f " 💥 { name } 异常: { e } \n " ) return False self . _print_summary () return True def _check_environment ( self ) -> bool : """ 检查 Python 版本和系统环境 """ version = sys . version_info if version . major < 3 or ( version . major == 3 and version . minor < 10 ): self . issues . append ( f " Python 版本过低: { version . major } . { version . minor } " ) return False print ( f " Python { version . major } . { version . minor } . { version . micro } " ) return True def _install_dependencies ( self ) -> bool : """ 安装项目依赖 """ req_file = self . root / " requir

The tutorial-to-production gap Every RAG tutorial follows the same arc. Load some...

Given the expansion of the fed/state/local/corporate surveillance net, do you find yourself expressing yourself less freely on the internet than you did five years ago?

Hi everyone, We've open-sourced Tri-Net v2, the official implementation accompanying our recently published Scientific Reports (Nature Portfolio) paper: "Tri-Net: Unified Deep Learning for Skin Lesion and Symptom-Based Monkeypox Detection" Rather than releasing only training scripts, we rebuilt the project as a reproducible research framework. Highlights: • Leakage-free data preparation pipeline • Multiple CNN backbones (ConvNeXt-Tiny, DenseNet201, Inception-ResNetV2) • Ensemble and feature-fusion strategies • Grad-CAM explainability • Cross-validation and statistical evaluation • Docker support • GitHub Actions CI • PyPI package (`pip install mpox-trinet`) • CLI for training, inference, and benchmarking The paper has already received over 1,100 article accesses in its first week, and we hope making the implementation fully open-source will help others reproduce, validate, and extend the work. GitHub: https://github.com/Sudharsanselvaraj/Synergistic-Deep-Learning-for-Monkeypox-Diagnosis PyPI: https://pypi.org/project/Mpox-Trinet/ Paper: https://www.nature.com/articles/s41598-026-61490-x I'd really appreciate feedback on the implementation, reproducibility, code quality, or ideas for future improvements. Contributions and issues are very welcome! submitted by /u/Rich-Fruit-326 [link] [留言]