research --daily

The tool is real and works; the "product manager" bundle it ships is a sketch, not a kit. GitHub's Spec Kit reached v1.0.0 around its one-year anniversary and sits at v1.0.4 as of September 2, 2026 (VERIFIED, CHANGELOG.md). Its core loop — /speckit.constitution → /speckit.specify → /speckit.plan → /speckit.tasks → /speckit.implement → /speckit.converge, run inside 30+ AI coding agents — genuinely separates the "what and why" (spec) from the "how" (plan), which is a PM-shaped division of labor even without any extra packaging. The repo also ships a real "Bundles: Role-Based Setups" feature meant to provision "a whole team persona (product manager, business analyst, security researcher, developer, …) with one command," and a product-manager bundle manifest genuinely exists. But read what it references: one real, installable extension (agent-context, which auto-syncs a project's AGENTS.md/CLAUDE.md after every spec or plan) — and a product-discovery preset that returns 404 at every path a preset would live at. GitHub's own README says why, one section after introducing the four role bundles: they are "packaging examples, not filled generated feature specs." The useful move this week isn't waiting for the PM bundle — it's installing the one piece that's real (agent-context) and running the actual spec → plan → task loop on something concrete.

In PMI's current standards, stakeholder work is not a soft skill — it is a named, repeating process with required artifacts, and the 2026 exam moved it to center stage. The PMP Examination Content Outline effective July 2026 splits the exam into three domains — People (33%), Process (41%), and Business Environment (26%) — and inside People, three of the eight tasks are dedicated to stakeholders: Engage stakeholders, Align stakeholder expectations, and Manage stakeholder expectations (SECONDARY — WebSearch summaries of the PMI ECO 2026 PDF and the studio's own ECO reference agree verbatim; pmi.org was not reachable this session). What the standard asks a PM to do is a loop, not a kickoff step: identify → analyze/prioritize → engage → monitor, repeated as the project evolves — the ECO's own enablers under "Engage stakeholders" read identify stakeholders, analyze stakeholders, analyze and tailor communication to stakeholder needs, execute the stakeholder engagement plan, optimize alignment among stakeholder needs, expectations, and project objectives, build trust and influence stakeholders (SECONDARY). PMBOK's 8th edition keeps Stakeholders as one of its seven performance domains (SECONDARY), and the loop is carried by three named artifacts a PM is expected to keep current: a stakeholder register (who they are, plus their interest, influence, and potential impact), a stakeholder engagement assessment matrix (each stakeholder's current vs desired engagement on the scale Unaware → Resistant → Neutral → Supportive → Leading), and a power/interest grid for prioritization (SECONDARY). The one move worth making this week: stop treating the stakeholder register as a one-time kickoff table and turn it into a living second-brain artifact — draft it with AI, keep the engagement matrix's current-vs-desired gaps visible, and let those gaps decide who you talk to next. Continuous re-identification is explicitly framed as a risk-management habit, not admin.

v1 and v2 are not two versions of the same software. They are two different kinds of thing. v1 was 34 markdown files and zero lines of code — a 25 KB core-workflow.md full of MANDATORY: and CRITICAL: instructions that you copied into your IDE's rules folder and hoped the model would obey. v2 is ~104,000 lines of TypeScript built around a deterministic engine that decides what runs next, with the LLM demoted from "the thing that decides the workflow" to "the thing that executes one stage well." AWS states the reason in its own spec: v1's "prescriptive stage definitions proved too opinionated, and that is where adoption friction arose," and the goal of v2 is to "march progressively towards autonomous software delivery — reducing human intervention as machine-checkable verification expands." The single sentence version: v1 asked an LLM to follow a process; v2 runs a process that calls an LLM.

Yes — and it is already happening, at the largest outsourcing firm in the world. In 2026 TCS said it intends to convert 1–1.5% of its associate base into forward-deployed engineers — roughly 5,900–8,900 people (SECONDARY, §4). But the interesting part is not that outsourcers are adopting the FDE label. It is why they can: the mechanism underneath FDE — an engineer embedded in the customer's environment rather than reading a spec about it — was measured in the outsourcing literature in 2011 under the name client embedment, and found to significantly improve knowledge transfer (Williams 2011, VERIFIED, §3). The outsourcing industry has always had the FDE mechanism. What it lacked was a reason to charge for it. AI supplies the reason. So the answer to "instead of or in parallel with BrSE" is: in parallel, but not symmetrically — BrSE and FDE cross different kinds of boundary, and only one of those boundaries is being eroded by AI (§3, §5).

Yes — it is a real, currently-posted job title at named companies, not a discourse artifact. But it is roughly two orders of magnitude rarer than Forward Deployed Engineer, and it is not the true ancestor of the idea.