Developer
45 entries tagged role Developer.
- Agent platform fundamentals Start where you can build: install the Namzu agent kernel, register a model provider, make your first call, and declare a tool with an explicit authority. Then step down a layer to Yuva, the sovereign kernel Cogitave is building to enforce those declarations on hardware it controls - including an honest account of what Yuva cannot do yet.
- Build on Cogitave Core Learn the harmonic core that every Cogitave product and agent shares: the Cogitave Core node and edge model, Cogitave Query, the native MCP interface, and how products project their state into a single queryable graph. By the end you'll be able to read the estate the same way humans and agents do. Day 0: this path is scaffolded - the module bodies are authored in a later content phase.
- Cogitave engineering standards Learn the standards floor that governs every repository in the Cogitave estate: the AGENTS.md rules, naming, commits and versioning, testing and quality, API design, configuration, secure SDLC, CI/CD, and observability and reliability. By the end you'll be able to make changes that pass the org gates by default. Day 0: this path is scaffolded - the module bodies are authored in a later content phase.
- Contributor onboarding The fast start for everyone who joins Cogitave: apply the non-negotiable AGENTS floor, inherit a repository's complete ruleset through the project baseline, work the propose-only request lifecycle, and open your first signed, Conventional-Commit pull request. This is the Tier-0 entry point every role track builds on. Day 0: this path is scaffolded - the module bodies are authored in a later content phase.
- Get started with Cogitave Massar Massar is the guardian agent that lets an authorized Cogitave operator open an audited terminal session on a customer device with no inbound port and no VPN. Understand the dial-out security model and how a session is bridged, then install, verify, and cleanly remove the agent on Linux and Windows using the real installers.
- Introduction to Cogitave Diyar Diyar is Cogitave's edge-autonomous platform for operating regulated field devices, where the device stays the sole authority over safety and evidence and each industry ships as a signed, pluggable solution. Understand what Diyar is, why safety and evidence stay local to the device, and how a device becomes a solution through signed profiles, verdict engines, and app packages.
- Patterns and golden paths Learn to build the Cogitave way: reuse first, discover before you generate, start from the patterns catalog, inherit a repository's complete ruleset through the project baseline, and use the decision guides for database, infrastructure, and model selection. By the end you'll reach for the named artifact before writing anything new. Day 0: this path is scaffolded - the module bodies are authored in a later content phase.
- Design and version a Cogitave API Shape a clean, consistent API against the Cogitave API design standard - resources, standard methods, typed errors, cursor pagination, idempotency - then version and deprecate it under the versioning policy so no consumer is ever broken without consent.
- Apply the naming standards Name a new identifier, file, repo, or branch the way the estate does - keyword-first, no redundant prefix, cased by role - and tell a functional keyword apart from a product codename, so your first artifact passes the naming gate by default.
- Apply the AGENTS floor State the seven non-negotiable rules every Cogitave contributor and agent obeys, say what enforces each one - a hook, a CI gate, an org ruleset, or policy-as-code - and apply them to your own first change.
- How a device becomes a Diyar solution Diyar turns a physical device into a certified solution through layered signed documents and firmware-compiled registries, not through custom code written per customer. A signed device profile configures the edge's hardware at boot; a certified verdict engine - a frozen product engine or one of the generic function blocks - decides pass or fail; and a three-document app package computes, offline, exactly what a device is authorized to observe, operate, or actuate. The module walks each of these three layers as they exist in the Diyar edge platform today, closes with one worked solution (ISPM-15) built entirely on that machinery, and states plainly where a capability is proven only against internal example fixtures rather than a field deployment - because that distinction is part of what you need to evaluate the product honestly.
- Build your first agent with Namzu Install the Namzu kernel, register a provider, make your first model call, and declare a tool with a typed schema and an explicit authority - locally, with no account.
- Read the pipeline that ships your change Follow a change from a pull request through the canonical CI stage set to a gated production deploy - the ordered gates a pipeline runs, why CI is the real gate, and how the deployment model promotes one signed artifact dev to staging to prod.
- Commits and versioning Write Conventional Commits whose type, scope, and breaking marker drive Semantic Versioning; see how release-please turns merged commits into a human-approved Release-PR, changelog, and tag; and how the trunk-based, protected-main model gates every release.
- Manage configuration and secrets Classify every value as a constant, a deployment parameter, or a secret; load configuration through the standard precedence chain, parsed once and fail-closed; and keep secrets out of git by referencing them at runtime and committing only encrypted-at-rest .env files.
- Core model fundamentals Explain why Cogitave Core is one canonical property graph that humans and agents both query, what its node/edge model and identity scheme actually are, and why ADR-0001 chose a labeled property graph as the substrate.
- Safety and evidence in Diyar Cogitave Diyar drives real industrial heat-treatment equipment without depending on a network connection, and this module explains the three mechanisms that let it do so safely and provably. First, a layered, hardware-first fail-safe design where every failure path — a wedged CPU, a blind sensor, a power cut, a lost serial cable — falls back to the heater being off, never the reverse. Second, a request model where the cloud and any remote client can only ask the edge to start a run; the edge alone verifies and can refuse, and there is no primitive anywhere in the system that lets a remote party force actuation. Third, an evidence pipeline that journals every reading locally before it is ever published, chains it so tampering becomes detectable, layers a Merkle history tree on top so completeness can be proven without shipping an entire run's history, and lets the cloud independently reconcile what it received rather than trusting the edge's word. Throughout, the module states plainly which parts of this are built and verified today versus named, not-yet-shipped follow-ups.
- Inherit the project baseline How a new repository is born on the paved road with its whole ruleset already inherited, how to tell always-on standards from the ones a product type pulls in, and how to find an existing pattern before writing anything new.
- Install and operate the Massar agent This module installs and operates the Cogitave Massar agent: the small, cross-platform binary a customer runs on a device so an authorized Diyar operator can dial in for an audited remote terminal, with no inbound port and no VPN. You install it with the CLI installer for your OS - install.sh on Linux, install.ps1 on Windows - confirm it is verified and running as a service, trace a session from open to close, reproduce the whole relay locally with the project's own dev harness, and remove it cleanly when you are done. Two facts are stated plainly rather than glossed over: today's supported install targets are Windows and Linux only, and every end-to-end proof described here is the local dev harness, not a production Diyar deployment.
- The native MCP interface to Core Read Core's MCP interface as the source of truth for how an agent queries the estate - why the surface is native rather than adapted, the protocol contract it commits to, and the tools and resources you call.
- Navigate the patterns catalog Find the canonical answer to "how does Cogitave do X" in the patterns catalog, read an entry's five fixed sections without confusing the pointer for the policy, and run the discover-before-you-build loop so you start every new piece of work from a named artifact instead of a blank file.
- Observability and reliability Instrument a service with OpenTelemetry-spec traces, metrics, and logs, understand why agent traces are kept as evidence, and reason about reliability through SLIs, SLOs, error budgets, and the policy that turns a spent budget into a release freeze.
- Open your first pull request Apply the floor, the baseline, and the lifecycle in one hands-on contribution - a signed, Conventional-Commit, docs-complete pull request that passes the gates and stops for human review.
- Operate from Day 1 Describe the Day 1 operating model - the pinned inner loop and the flow-based outer loop - state the parity contract that keeps the inner loop honest, name Cogitave's flow-based ways of working and why ADR-0025 chose it over Scrum, and explain why the human gate stays an exception inside the flow.
- Project products into Core See how content projects into Cogitave Core as typed, content-addressed nodes rather than separate silos, and how the fact registry's cite-not-restate rule and fact-drift scanner keep one owner per fact across the estate.
- Query the estate with Cogitave Query Learn how Cogitave Query resolves a request against the canonical graph - lexical BM25 and dense HNSW vectors fused by Reciprocal Rank Fusion, a graph-aware rerank and ranking signals, and the bounded, read-only query_graph profile agents call directly.
- Reliability and SRE Reason about a service's reliability targets the way the reliability standard does - set an SLO from the user's journey, compute the error budget it buys, and operate the service against that budget with burn-rate alerts, sustainable on-call, a toil cap, and the freeze that stops shipping when the budget runs out.
- Respond to incidents Walk the incident-response flow end to end - detection, severity declaration, single-commander roles, containment through a runbook, communication, recovery, and the blameless postmortem - and see how business continuity and disaster recovery extend the same discipline to a region loss or a destructive event.
- Reuse-first engineering Explain why AI-assisted development diverges without a counter-force, state the discover-before-generate hard rule and what enforces it, and justify a from-scratch decision the way ADR-0003 requires - as a reasoned exception, not a default.
- Run agentic operations Explain what agentic operations means at Cogitave, state the draft-vs-act rule that decides when an agent acts unattended versus when it stops for a human, and name the real fleet of scheduled and operations agents that run the estate.
- Build with the secure SDLC State the security baseline - threat modeling, least privilege, and IAM - and follow the secure development lifecycle that shifts security left, so each stage of a change carries its own security gate instead of a check bolted on at the end.
- Test to the standard and pass the quality gate Learn how Cogitave tests a change - the pyramid/trophy shape, the diff-coverage and mutation gates, flaky-test quarantine, the runnable harness, and the craftsmanship review bar - so you can test your own change and get it through the gate.
- Understand Cogitave Diyar Cogitave Diyar is the platform layer of the Cogitave cloud: multi-tenant management for distributed field devices that have to keep working, and keep proving what they did, even when the network is unavailable. This module introduces the problem Diyar solves (a regulated, unattended field process — starting with ISPM-15 wood-packaging heat treatment — that must run and produce trustworthy evidence with no network), the edge-autonomous model that solves it (the device is the sole authority over safety and evidence and runs fully offline), the platform/solution split that lets a new regulated process plug in as a certified verdict engine plus a signed device profile rather than a fork, and a tour of the architecture from the edge binary through the cloud/on-prem control plane to the client surfaces — including an honest account of what is still early (the kiosk and portal UIs) and what is still gated pending hardware validation.
- Understand Cogitave Massar Cogitave Massar is the guardian remote-console agent that gives an authorized operator a terminal on a customer device without opening an inbound port or requiring a VPN. This module explains what Massar is and the one job its agent performs, why an outbound-only connection model removes the need for inbound access, how a session moves control messages and terminal bytes across the agent-broker-operator chain, and how a device authenticates while Diyar-side RBAC and audit authorize and record who connects. It also states plainly which parts are shipped today - the CLI installers with a static per-device token, Windows and Linux support - and which are still previews, such as the graphical enrollment wizard and macOS support.
- Understand Yuva, the sovereign kernel Why an agent platform builds its own kernel, what a fail-closed boot and formally verified leaves actually prove, and an honest account of Yuva's current status.
- Use the decision guides Learn the shared shape behind Cogitave's database-selection, infrastructure-selection, and model-selection guides - a default, a decision tree, and an ADR-gated deviation rule - and walk a real workload to a justified, recorded choice.
- Work the request lifecycle Move a change through the seven-stage request lifecycle, understand why the write tools only propose, and read the Definition of Done that decides when a request is actually done rather than merely worked on.
- Agent identity and capabilities Every Cogitave agent acts under its own identity inside an explicit least-privilege capability grant, in a sandbox, with every action recorded as evidence. What that model guarantees, and where a human is still required.
- Check your environment Use the namzu operator CLI to verify a machine before debugging an agent - runtime version, installed packages, and whether the provider you registered is actually reachable.
- Choose a provider The model providers Namzu ships as drivers, how to register one, what changes when you switch, and which to pick for local development, hosted inference, aggregation, or an OpenAI-compatible endpoint of your own.
- Glossary The terms used across Cogitave documentation and training, defined once - agent kernel, capability grant, provider driver, sandbox, sovereign unikernel, MCP, evidence, and the words that are easy to assume.
- Packages reference Every published Namzu package and what it is responsible for - the kernel, the sandbox and telemetry layers, the operator CLI, the file registry contracts, and the eight model provider drivers.
- Quickstart - run your first agent Install the Namzu kernel and one provider, send a first message, and see the shape of a response. Local-first with Ollama, no account and no hosted service required.
- What Namzu is Namzu is an agent kernel for TypeScript, not an application framework. What that distinction buys you, what the kernel owns, what it deliberately refuses to own, and how the layering keeps your stack yours.
- What Yuva is Yuva is a from-scratch, agent-native sovereign unikernel in no_std Rust, with formally verified leaves and a boot that fails closed. What it is for, how it is verified, and exactly which parts are not live yet.