Talomnia Workforce
The first Talomnia product: professional Digital Professionals and teams for B2B tasks — research, development, technical and product analysis, AI-first consulting and adjacent work the existing system can already perform.
What you can order
Client work categories: the task you hand over, what you get back, who performs it, and how it is estimated. Every category links to the capabilities that perform it.
Market & Competitive Research
The task: Understand the market, competitors, pricing and buyer behaviour before a decision is made — about a product, a niche entry or positioning. Open deliverables, team, estimate and evidenceWhat you get
- A research report with methodology, sources and limitations
- A competitor and adjacent-alternatives map with a comparison table
- Pricing benchmarks for the niche
- A recommendation with its reasoning and applicability bounds
Typical team: A research analyst, a reviewer, a source auditor.
How it is estimated: Time & Materials with a Budget Limit agreed in advance; the scope is fixed before the start.
Which capabilities perform this work:
Software Development
The task: Design and build a service, module or integration — with tests, documentation and a verifiable execution history. Open deliverables, team, estimate and evidenceWhat you get
- Working code in a repository with its change history
- Automated tests, reproducibly green
- Technical documentation following the adopted taxonomy
- An execution report with measured cost and time
Typical team: A developer, a code reviewer, a QA engineer.
How it is estimated: Time & Materials with a Budget Limit agreed in advance; the scope is fixed before the start.
Which capabilities perform this work:
Architecture & Technical Research
The task: Choose a technology or an architecture on evidence — compare the options, record the decision and its cost, without relying on taste. Open deliverables, team, estimate and evidenceWhat you get
- An architecture decision recorded as an ADR with the alternatives considered
- A technology comparison with criteria and measurements
- Diagrams and a description of the system boundaries
- An adoption plan with risks and rollback points
Typical team: An architect, a technical researcher, a reviewer.
How it is estimated: Time & Materials with a Budget Limit agreed in advance; the scope is fixed before the start.
Which capabilities perform this work:
Product Analysis
The task: Understand what is happening to a product — where users or money are lost, which hypotheses to test and how to measure the outcome. Open deliverables, team, estimate and evidenceWhat you get
- An analytical report with the data and methodology
- A list of testable hypotheses with success criteria
- A prioritisation with its reasoning
- Metrics to monitor after the changes
Typical team: A product analyst, a reviewer, a data auditor.
How it is estimated: Time & Materials with a Budget Limit agreed in advance; the scope is fixed before the start.
Which capabilities perform this work:
DevOps / Infrastructure
The task: Set up reliable delivery and operations — CI/CD, migrations, observability, deployments without manual server edits. Open deliverables, team, estimate and evidenceWhat you get
- A working build-and-deploy pipeline
- Database migrations with a verified rollback
- Monitoring with verified alerting
- An operations runbook
Typical team: A DevOps engineer, a reviewer, a recovery-verification operator.
How it is estimated: Time & Materials with a Budget Limit agreed in advance; the scope is fixed before the start.
Which capabilities perform this work:
AI-first Transformation
The task: Understand which of your business processes can be handed to digital professionals, where to start and how to verify the result — on your material, not in theory. Open deliverables, team, estimate and evidenceWhat you get
- A process map with hand-over suitability assessment
- A pilot plan with acceptance criteria
- Recommendations on quality control and autonomy boundaries
- A consultation summary report
Typical team: An AI-first process consultant, an analyst, a reviewer.
How it is estimated: A separate consultation service; the scope and the Budget Limit are agreed before the start.
Which capabilities perform this work:
Documentation & Knowledge Engineering
The task: Turn a team's scattered knowledge into structured documentation people actually use — references, guides, knowledge bases. Open deliverables, team, estimate and evidenceWhat you get
- Documentation in the four-part taxonomy (how-to, reference, explanation, tutorials)
- A knowledge-base structure with its maintenance rules
- Migrated and verified content
- Freshness-maintenance rules
Typical team: A knowledge engineer, a technical writer, a reviewer.
How it is estimated: Time & Materials with a Budget Limit agreed in advance; the scope is fixed before the start.
Which capabilities perform this work:
Custom Professional Work
The task: A task that does not fit the categories above. Describe it — we will answer honestly whether we can do it, how the result will be evidenced and what it will cost. Open deliverables, team, estimate and evidenceWhat you get
- A feasibility assessment with its reasoning
- The scope and acceptance criteria before the start
- The result with execution evidence
- A report with measured cost and time
Typical team: The team is assembled for the task from the available roles and capabilities.
How it is estimated: Time & Materials with a Budget Limit agreed in advance; individual contracts for enterprise.
Which capabilities perform this work:
Payment model
- Time & Materials: the team composition, rates, an approximate estimate and the Budget Limit — the maximum allowed budget — are agreed in advance. You are billed for actually performed work.
- For enterprise: individual contracts, postpaid billing, acceptance acts.
- There is no public rate card yet: rates are agreed within a specific engagement.
How ordering works
Every task follows the same path: task description, selection of roles and knowledge, economics fixed before execution, execution, delivery with evidence, acceptance.
How this work is performed
The categories above are performed by capabilities from the Capability Atlas — the public catalog of capabilities applied in real tasks. It is not a marketing list: every row is linked to execution.
- skills
- 43
- blueprints
- 16
- other capability types
- 8
-
component-library
Seventeen framework-neutral component specifications covering every site surface, from buttons and navigation to the load-bearing evidence set. The Editorial Evidence Signature gives Workflow, Research and Atlas one typed, early trust frame without turning completion, publication or sanitization into a validation claim. Global contracts hold for every component: design tokens only, i18n copy, server-rendered content, visible focus and rendered theme/mobile acceptance.
-
design-system-atlas
A staged path that turns digest-pinned design research into an enforceable design system: tokens, typography, spacing, navigation, imagery, tables and bilingual discipline authored as versioned knowledge artifacts, consumed by the site build, and gated by measurable checks that can fail. Research comes first and is carried as provenance; the system lives as reusable, published artifacts instead of one-off styling decisions.
-
design-to-code-loop
A staged, gated loop that carries accepted design decisions into verifiable product code: frozen context projection, digest-pinned research, multiple directions, independent selection, visual asset direction, RED implementation contract, code vertical slice, screenshot/vision critique, interaction/accessibility tests, bounded correction loop, and evidence bound exactly to the consumer commit and release. Enforces author/reviewer separation and returns material changes to the owning source artifact.
-
editorial-evidence-atlas
Reusable proof-first long-form page blueprint with semantic locale registries, an evidence spine, conditional chapter navigation, full-shell figure bands, and source-backed provenance.
-
evidence-bearing-verification
A reuse pattern for building verifications whose results count as evidence, not claims. A check must first demonstrate that it can fail, via a code mutation or a negative fixture, before its pass is accepted. Every run is recorded as an immutable, digest-bound observation with provenance, and the pass/fail interpretation stays separate from the observation itself. No producer may verify its own output, and success asserted without every required evidence item is treated as unestablished.
-
evidence-spine
Defines Claim, Capability, Execution evidence, and Verification evidence as linked reusable types with honest absent and target states.
-
knowledge-evolution
A pattern for revising an existing knowledge artifact when evidence attributes a deficiency to it; an unsuccessful run alone is not enough, and ambiguous attribution is recorded as an unresolved cause with no successor created. The successor keeps the same logical identity, takes a new revision and content digest, and names its predecessor explicitly. Earlier bytes and every contract that pinned them are never rewritten; the successor re-enters validation and approval as a candidate and affects only future selections.
-
knowledge-expansion
A pattern for adding a genuinely new knowledge artifact when a recorded Gap proves that no existing one covers a requirement; taste or a low-ranked candidate is never a starting point. The candidate receives a new logical identity and stays quarantined, excluded from selection, until it passes evidence-bearing verification and explicit approval; self-attestation cannot promote it. Publication is scoped under the artifact lifecycle policy, any public projection must pass the sanitization constraint, and previously issued contracts keep their exact pinned dependencies.
-
knowledge-repo-bootstrap
A repeatable procedure for standing up a private knowledge repository for a product layer: targeted spec intake, format research against real exemplars, an architecture decision record, a scaffold with lifecycle and sanitization artifacts plus security policy files, and seeding with the real artifacts the bootstrap itself produced. The indexing path is documented from the target service's own documentation, never invented, and validation walks the acceptance checklist item by item with recorded evidence. Validated in practice during the Talomnia launch (TALO-0002).
-
lane-handoff
A reuse pattern for replacing a running agent lane with a fresh session without losing what the lane established. The hard part is not ending a session but enabling the successor to continue, so the handoff carries the brief, the decisions already taken together with the reasoning that produced them, what was rejected and why, the artifacts and pull requests in flight, and above all the verification record — what has been checked, by which command, with what result. A handoff that loses the verification record converts measured acceptance into hearsay, leaving the successor to re-accept work on trust or to redo work that already passed. Every carried claim is tagged as verified or assumed, and the successor re-establishes the perishable ones before relying on them.
-
long-form-document
The page type for a document that is read rather than scanned: a research study, a white paper, a long argument with tables, graded claims and a source manifest. It is not the structural page type — a 111KB argument with twenty-one sections needs its own contents navigation and a way back from anywhere in it, a reading measure stated in characters rather than a container width, tables allowed to leave the measure but never the page, a source manifest whose long addresses may break across lines, and a reading rhythm in which the section is the unit. Stated per template: what a reader must be able to do at 320px, what the document does when its own length works against it, and which checks may go red. The page-templates blueprint's research entry is narrowed to point here.
-
page-templates
Fourteen page templates covering every section of talomnia.com, from the home page and workflow case pages to the investor room, pricing and forms. Each template fixes its block sequence, the components it uses and its database data source: repeated content always renders from data, never from hardcoded copy. Honesty hooks such as status callouts, disclaimers and provenance stamps are structural elements of the templates, and mobile behavior and Russian-English parity are specified per template rather than left to implementation.
-
payment-provider-adapter
Isolates all payment logic behind a single PaymentProvider interface with a Stripe test-mode implementation, guarded by a feature flag that is off by default. While the flag is off, pricing CTAs collect pre-order intent only: no network call, no charge. When it is on, the adapter refuses anything but a test key, so a live key in configuration is treated as an error rather than an accidental go-live; enabling real payments remains an explicit operator decision, and the provider can be swapped without touching pricing logic.
-
projection-pipeline
A one-way, reproducible pipeline from the Git knowledge repository into the site database and the Capability Atlas. Changes are born only in Git; the loader is a pure function of the tree, rebuilds are identical, and the site runtime holds read-only database rights, so a back-write is a permission error rather than a code-review promise. A two-layer lifecycle gate keeps non-public artifacts physically out of the projection, a sanitizer aborts the load on any internal detail, and every invariant carries a mutation test that has been shown to go red.
-
repo-provisioning-sanitized
Provisions the public showcase repository and the private site and backend repositories with the sanitization discipline built in from the first commit. The showcase repo carries an explicit disclaimer that it is a sanitized execution trace, not a production working repo, and its CI gate is blocking and mutation-proven, with a red and a green run recorded as evidence. The private repos receive the ecosystem security policy files, all commits use the verified service-account identity, and no real paths, hosts or IP addresses appear anywhere in the public contour.
-
task-to-contract
The pattern that turns a task intent into an issued Knowledge Contract through five stages, propose, validate, select, assemble and issue, run over a pinned repository snapshot. Every reference entering the contract is pinned by revision and content digest, admissibility is decided by six compatibility conditions, and a frozen Resolution Receipt is kept for every resolution, successful or not. If no compatible set covers a requirement, the outcome is a recorded Gap, never a weakened contract; assembly and issuance remain separate acts, and the blueprint itself grants no permission.
-
bilingual-content
The ability to produce and maintain Russian and English content with full parity of meaning and a single glossary-backed terminology across the site, the White Paper, the Pitch Deck and research pages. Terminology drift between languages or between documents counts as a defect. Evidenced by the bilingual materials the same content stack already publishes in the ecosystem; launch requires the highest level, cross-document consistency in both languages.
-
data-modeling-projection
The ability to design the Talomnia data layer: the minimum entity set for workflows, research, Atlas entities and requests, with bilingual site-facing fields and graph relations rather than a tree; request minimization with the Support Center as the source of truth; and a one-way reproducible projection from Git through the search index into the database and the site, filtered so only public-sanitized artifacts reach the public surface. The top level requires mutation proof: deleting a source record demonstrably changes the page.
-
design-systems
The ability to research, define and ship a design system: concept, style guide, component set, page templates, mobile adaptation and accessibility criteria, authored as knowledge-repository entities that project into the Capability Atlas rather than living only as files in a site repository. The record honestly notes the gap: no prior system-level design artifact existed in the ecosystem, so the competency entered at draft and was validated by delivering the Talomnia design system.
-
devops-operations
The ability to provision and operate the production hosting path for talomnia.com: DNS and Cloudflare with TLS and cache invalidation, versioned web-server configuration, CI/CD with operator-confirmed production deploys, separated staging and production contours, secrets only through the ecosystem secret store, backups with a tested restore, and monitoring whose alerts demonstrably reach a channel that is read. The top level requires resilience proven, not assumed.
-
integration-engineering
The ability to connect two services contract-first, exercised on the link between Talomnia forms and the Arcanada Support Center: native UI without an iframe, status sync via webhooks or polling, retries with idempotency keys, an audit log, request linking by identifier, and contract tests between the two sides that block release on incompatibility. Built on the ecosystem's codified internal HTTP integration patterns and a Support Center already running in production.
-
market-research
The ability to produce decision-grade market research: ideal customer profile, pains, competitor landscape, price points, alternatives and a first sellable service, answered from verifiable external sources with methodology, source list, limitations and versioning. Every output carries the pre-commercial self-use validation marking, and hypotheses stay marked as hypotheses. The top level is a pricing recommendation defensible to an operator or investor audience.
-
technical-research-adr
The ability to run the research-to-decision cycle for technology choices: inventory what the ecosystem already runs, prefer the existing supported option unless it fails the requirements, evaluate alternatives, and fix the decision in an architecture decision record before implementation starts. No new technology dependency is introduced without demonstrated necessity. The top level resolves interacting choices, such as stack, database and analytics, as one consistent set.
-
web-fullstack-delivery
The ability to deliver a production bilingual database-driven website end to end: pages where repeated content is rendered from a database, full RU/EN parity, dark and light themes without a flash of the wrong theme, mobile-first layout, WCAG 2.1 AA accessibility, search metadata and Cloudflare-cached public pages while forms stay uncached. Evidenced by existing production sites in the ecosystem built and operated by the same agent stack.
-
acceptance-by-pr-decision
A procedure that ends every delivery in a recorded pull-request decision. Each acceptance criterion from the originating issue is checked against the delivery with a check that can fail, and the observed result is captured per criterion. If every criterion holds, the pull request is merged and the merge commit is the acceptance record; if any fails, changes are requested naming the criterion and the observed result. Editing the delivery to make a criterion pass is rejected outright, and the decision is logged in the workflow ledger.
-
accessible-evidence-diagrams
Rebuilds source-backed figures as typed semantic HTML with supplemental safe SVG, stable IDs, localized alternatives, visible long descriptions, machine provenance, and red-capable checks.
-
admissibility-check
A procedure that decides whether a candidate set may enter a Knowledge Contract by evaluating six compatibility conditions in full: eligibility, coverage, exclusion freedom, dependency closure, constraint satisfiability, and current selection authority. The verdict records a pass or fail per condition, with an exact invalid-state code for every failure. An inadmissible set is rejected rather than repaired in place, unknown constraint satisfiability is never treated as true, and unverifiable authority fails closed.
-
adr-authoring
A procedure for writing an Architecture Decision Record before implementation starts, so a decision is recorded rather than rationalized after the fact. It begins with an inventory of what the ecosystem already runs, states the governing requirements verbatim, and enumerates realistic options with their fit, operational cost and exit path. The record must exist before the first implementation commit and must name how the decision can be reversed; escalation replaces a decision only when several substantially different options carry major architectural consequences.
-
ai-quality
Five working disciplines for AI-assisted development: decomposition into methods of at most fifty lines, tests before code with edge-only mocking, an approved architecture skeleton before implementation, one-method-at-a-time focus, and deliberate context management. It presumes gathered requirements and an explicit definition of done before coding starts. The work leaves behind pre-written tests, a named test for every clause of a success criterion, and a clean linter run after each TDD cycle.
-
context-window-lifecycle
Manages the context window of an orchestrated agent lane as a quality property rather than as capacity. The occupancy of a running lane is read from the session's own usage record, which is exact whether the lane is busy or idle, never from the terminal surface, where the figure is rendered only while the lane is idle. Occupancy above the declared threshold is treated as a defect in the lane's output rather than as a scheduling constraint, because a saturated window degrades into plausible-but-wrong work instead of failing loudly. Three remedies are distinguished by cost and by what each loses: compaction, handoff to a fresh session, and completing the current unit before doing either.
-
customer-narrative
A method for authoring customer-facing service copy on commercial surfaces. Every offer is written as a client work category — the task handed over, a concrete deliverables list, the typical team composition, the estimation method, evidence links into the Capability Atlas and one call to action — with customer language opening before product mechanics and technology terms, internal entities demoted to an evidence level rather than deleted, honesty invariants inherited from the presentation policy (no invented cases, no unbenchmarked comparisons, no rate figures, no indicative-mood commercial-policy promises), Russian/English parity, and the copy shipped as projected data so its presence is mutation-verifiable.
-
datarim-doctor
Diagnoses and migrates the framework's operational task files to a strict machine-parseable schema: thin one-line indexes, per-task description files with a closed twelve-key header, and canonical per-task archive documents. Every fixing run is wrapped in a data-loss safety contract: a full backup before any mutation, a count invariant that restores the backup if entries are lost, and a post-fix re-scan proving zero findings and that an immediate second run changes nothing.
-
datarim-system
The always-loaded core rulebook of the Datarim workflow: where state lives, how task identifiers are formed, why operational files stay machine-parseable one-line ledgers with a per-task description file, and in what priority order operator instructions, skills, and defaults resolve. It requires an initialized workflow directory before any write and routes deeper questions to focused fragments. Compliance shows up as pointer-based index lines and a recorded disposition for every closed task.
-
db-migration-execution
A procedure that brings a target database to the exact state of the committed migration chain. Migrations are applied in order under the owner role, schema is never hand-edited on the server, and access grants travel inside the chain, failing loudly instead of being repaired ad hoc. Write domains between projection tables and the operational area are enforced, parity is verified by an empty schema diff after apply, and applied migrations and the parity result are recorded in a report. Credentials never leave the host or enter a repository.
-
deploy-broker-operation
A procedure for shipping a release through the deploy broker, the only channel allowed to mutate the host. The bundle is verified before any host change, deployment flips an atomic, reversible release switch with the previous release recorded, and a loopback health probe treats any non-OK response as a failed deploy. On failed health or content verification the release is rolled back and health re-verified; edge configuration changes go through the repository and the broker as well. Production deploys only after staging is verified green, with broker outputs and probes captured as evidence.
-
design-direction-exploration
Produces three to five materially distinct directions, compares them against one evidence-backed matrix, records dissent and rejection reasons, and freezes an independently reviewed selection by identity and digest before implementation.
-
design-research
A method for grounding design work in verifiable external evidence before any visual decision is made. Current product and investor-facing sites and recognized design guidance are examined with a fixed extraction structure, and the outcome is a research note in which every claim traces to a fetched source with an access date, with digest-pinned snapshots for the load-bearing references. Successor design artifacts consume the note as provenance, so the design stage is gated by citable research rather than taste.
-
diataxis-docs
Mandates the Diátaxis taxonomy for every managed repository and product site: documentation splits into exactly four categories by reader intent — tutorials, how-to, reference, explanation — through a closed mapping table, with no fifth buckets such as FAQ or troubleshooting. New repositories get the layout at scaffolding time; existing ones are soft-audited by a filesystem drift check that warns without blocking. Evidence of compliance is the four-directory layout with stub files and a mapping decision for every content type.
-
digest-pinning
A procedure that turns any reference into a closed, immutable pin. The reference must resolve to exactly one revision in the pinned snapshot; mutable forms such as branch names, tags, version ranges and live URLs are rejected outright. The revision payload is canonicalized, its content digest computed, and the pin recorded as revision plus digest with an exact version predicate, then re-verified by recomputation from the canonical bytes. Every direct and transitive dependency is pinned the same way, so the result resolves without network access or mutable names.
-
explanatory-affordance
How a Talomnia surface explains its own vocabulary at the point of use. An evidence surface that names a quantity — wall, active, disposition, human cost — owes the reader its meaning there, not on another page: sending someone to the glossary to read a column header defeats the page. The affordance is operable by pointer, by touch and by keyboard, announced to assistive technology, driven by the page's language rather than the browser's, and rendered from the SAME projected definition the glossary renders, because two hand-maintained copies of a definition drift. It may not cover the data it explains, may not move the layout it sits in, and may not fire because a pointer crossed it on the way somewhere else. A title attribute satisfies none of this and is refused.
-
factcheck
Verifies a text before publication without rewriting it. Every checkable claim is extracted into a graded table, then verified against authoritative sources in order of importance — three or more independent sources for critical claims — and given an explicit verdict with a confidence score. Corrections are minimal, preserve the author's voice and language, and each cites its source in an inline note. The original is modified only after author review, with backups in place and a verification report left behind.
-
frontend-ui
A defect-catching checklist for any change to HTML, CSS, templates, or visual components. It enforces light-as-default theming with class-based dark overrides, screenshot verification of both themes across mobile, tablet, and desktop viewports, language parity for multilingual sites, and baselines for accessibility, performance, and social metadata. A successful HTTP response is never accepted as proof a page looks right: the QA stage runs an automated browser pass that leaves screenshot evidence, while aesthetic judgment stays with a human.
-
human-summary
Ends each verification and archive stage with a recap a non-programmer can read: what was asked and done, what worked, what remains open, and what happens next — 150 to 400 words in a fixed four-section shape headed by the task identifier so the recap stands alone out of context. Plain language is enforced by an allowlist-then-banlist vocabulary check with a bounded verbatim-quote escape hatch and a graded severity ladder that can reject the recap outright. Criteria verified only once, without an automated guard, must be disclosed.
-
immutability
The contract that keeps pipeline artifacts honest: requirements, plans, design decisions, tests, checklists, and visual baselines must never be weakened to let a failing deliverable pass, and every verification criterion must be falsifiable. When an artifact genuinely cannot be satisfied, the executor records a return-to-source entry — original text, reason, proposed revision — before any change, escalates to the operator, and routes work back to the stage that owns the artifact. Changes happen by formal supersession, never silent edits.
-
infra-automation
Operational patterns for running commands safely across a server fleet: host keys verified and mesh reachability checked before any batch, non-interactive fail-fast SSH, a one-server trial before fleet-wide execution, and a hard ban on batched destructive commands. It covers network-first outage debugging, engine-level data inventory before migration or decommission, and the rule that any on-server artifact a verification gate consumes must be version-controlled first. Reachability results and operation output are logged as the audit trail.
-
long-form-typesetting
Defines how authored prose becomes typeset HTML on a Talomnia surface, which until now nothing did: the closed inline subset a renderer converts, the heading-and-label discipline that keeps a document outline readable, how lists, tables, blockquotes, code, citations and links are set, the Russian and English conventions for dashes and quotation marks, how numbers and currency are written in each language, and the measure a sustained-reading column is bounded to. The clause that decides the failure case is the one about UNEXPECTED markup: a renderer's behaviour on markup outside the subset is defined here rather than left to chance — it escapes first, converts a closed set, and renders everything else literally, while the ingest gate and the published-surface sweep refuse it loudly. Markup a reader can see is a defect of correctness, not of polish.
-
motion-design
Governs every motion on a Talomnia surface beyond the theme swap: the declared easing and duration, how staggering is bounded, how a reduced-motion request is honoured by removal rather than by slowing, and — the part that decides more cases than the parameters — when motion is simply wrong. Motion is admissible only when it carries meaning a static frame cannot: orientation, continuity, or feedback for an action the reader took. Decoration is not a reason. An ambient layer is held to stricter limits than an interaction: it must be imperceptible while reading, disabled outright under reduced motion, never above content in stacking order, incapable of degrading measured text contrast, and it must degrade to a static background when JavaScript or the device cannot carry it. Motion that cannot be checked is out of contract.
-
nginx-version-compat
A planning checklist for any task that edits nginx configuration. Before a single directive is written, the procedure probes the running server for its exact version and compiled-in modules, then maps HTTP/2 and HTTP/3 syntax to that version, because directive forms changed between releases and distributions pin old branches. The plan must record the probed version, state TLS settings explicitly, and require a passing configuration test before any reload.
-
node-bundle-assembly
A procedure that assembles a self-contained Node release bundle from a committed repository checkout with a frozen lockfile; any lockfile drift aborts the build. Dependencies are installed frozen, the project is compiled, and the unit suite must pass, with environment-dependent suites skipped loudly rather than silently. The bundle carries the compiled output, static assets and production-only dependencies; development toolchain, test trees, version-control data and secrets never ride along. Before shipping, the bundle is self-checked against the deploy broker's acceptance floor.
-
playwright-qa
A QA contract that adds real-browser evidence to frontend changes. It fires only when changed files touch rendered markup or styles, resolves the browser tool through a fixed chain (operator override, CLI, MCP server, environment browser), and serializes concurrent runs on a per-task lock. Each pass leaves a timestamped run directory with screenshot, trace, log, and a summary that the QA report cites. Missing tooling or a lock timeout is recorded as a finding, not a hard failure, so the pipeline keeps moving.
-
pre-ledger-accounting-reconstruction
A procedure for restoring the accounting of work that happened before it was being metered, without inventing measurements. The reconstruction records only what surviving evidence can support, marks every recovered figure as reconstructed with its basis, and leaves everything else explicitly not measured rather than zero. A basis must be a countable property of a surviving artifact, not an assumed rate applied to a proxy; where an assumption is unavoidable it is stated as an assumption so a reader can dispute it. Human contribution is recorded in time even when no defensible monetary rate exists, because an unpriced contribution is still a contribution and zero would erase it.
-
research-workflow
A structured method for investigating external context before planning or during implementation. Depth scales with task level: a ten-point checklist for new systems, a five-point pass for enhancements, none for quick fixes. It covers versions, breaking changes, best practices, compatibility, advisories, and the existing codebase, verifies plan assumptions against live state before code is written, and confirms third-party endpoint contracts with real probe requests. Findings land in an insights document where every claim cites its source and unverified knowledge is flagged.
-
resolution-receipt
A procedure that freezes an immutable receipt for every resolution, successful or not. The receipt records the normalized task intent, the snapshot digest, the resolver configuration identity, and every candidate considered, with machine-readable reason codes for each rejection; prose alone does not count. Conflicts, ambiguity and search completeness are recorded explicitly, naming the boundary when the search stopped early. The receipt is canonicalized and digest-frozen, distinct in identity from contract and issuance, and never mutated: a correction is a new receipt referencing the old one.
-
sanitization-gate
Turns the sanitization rules into an automatic, blocking CI check on every public publication path. Two detector layers work together: a version-pinned generic secret scanner and a project denylist of internal identifiers, mirrored into CI as patterns rather than values. The check fails closed, an allowlist entry requires an in-repo justification with an expiry, and the gate is mutation-proven: a planted forbidden token must turn CI red, because a gate that has never been red proves nothing.
-
security-baseline
The canonical security floor for shipped artifacts: eleven rule clusters covering shell and Python hygiene, secrets, supply chain, documentation treated as code, repo hygiene, CI gating, drift response, a branch-integration floor, and an untrusted-content boundary gate. Each cluster is enforced by a required CI job that blocks merge; boundaries where untrusted bytes reach a model also require a distinct adversarial review, since green CI cannot model prompt injection. Every suppression is registered with reason, expiry, and reviewer.
-
semantic-editorial-composition
Builds deterministic locale-specific long-form documents from stable authored keys, with editorial rhythm and semantic rather than pixel parity.
-
seo-hreflang
How to give a bilingual, path-prefixed site a correct search surface so the Russian and English trees never compete. Every page renders its canonical, hreflang and Open Graph tags from a single layout function, so no page can ship half a set; the sitemap is generated from the same route table and database slugs the pages themselves use, so a live URL missing from it is a bug by construction. Verification is written as checks that can go red, including a mutation form where deleting a database row must remove its URL from the sitemap.
-
success-criterion-measurement
A procedure that decides a success criterion strictly from evidence. The criterion must declare an observable predicate and its evaluation version; each required evidence item must be present, digest-bound, and carry provenance and collection conditions. If any item is missing, the outcome is recorded as unestablished, neither passed nor failed, and self-declared success by the producer is rejected as a claim that never enters the evaluation. The result is frozen in a measurement record binding the criterion revision, the evidence digests, the predicate result and the evaluator identity.
-
systematic-debugging
A four-phase discipline that forbids proposing fixes before the root cause is understood. Phase one reads the full error, reproduces the failure, and instruments component boundaries to see where data flow breaks; phase two compares against a working example; phase three tests a single written hypothesis with the smallest possible change; phase four creates a failing test, lands one fix at the source, and verifies. After three failed fixes the procedure stops and questions the architecture instead of attempting a fourth patch.
-
tech-stack
A selection method for technology stacks in new projects, services, and modules. A trigger classifier separates routine same-domain work, which uses the default recommendation, from cases that need a full proposal: new scaffolds, cross-domain components, migrations, or explicit operator requests. A proposal presents two or three candidates assessed across ten factors, from domain fit to escape velocity; the operator chooses, and the choice is recorded as a decision note bound by the immutability contract. Dependency versions are verified against live registries, never training data.
-
testing
The testing contract for implementation and QA flows: a pyramid of mostly unit tests with fewer integration and end-to-end flows, plus a set of gates against false-green suites. Tests must exercise the real production path (raw fixtures through the real mapper, driver serialization simulated, upstream layers stubbed to passthrough), mutation checks must go red when a guard is broken, infrastructure skips must probe and name the missing dependency, and reported test counts are derived mechanically from the runner. Detailed gates load as fragments only when the matching situation is active.
-
theming-anti-fouc
Implements dark and light theming and language persistence with no flash of the wrong theme at load. A synchronous inline script at the top of the document head resolves the stored choice, then the system preference, before any stylesheet paints; client-framework state may only mirror that decision, never make it. The pattern keeps CDN caching intact by avoiding cookies on cacheable responses, covers no-JS users through a media-query fallback, and is verified by a first-paint screenshot matrix across stored and system theme combinations.
-
ui-source-selection
Decides, before a component is written, whether it should be taken from an existing trusted source, adapted from one, or authored here — and records the decision with the evidence that justified it. The first question is not quality but installability: a component library that assumes a client framework the product does not run is not a cheaper option, it is a different architecture, and treating it as a shortcut imports a runtime the product deliberately refused. A source is admissible only when its licence is recorded, its runtime assumptions are met by the target surface, and its accessibility and motion behaviour can be checked against our own contracts rather than trusted. Copy-into-the-repository distribution is preferred over a runtime dependency because it leaves the code auditable and editable; it does not make the code ours, and provenance survives the copy.
-
utilities
An index of native shell recipes for routine operations: dates and time zones, hashing and random values, encoding, text case conversion, validation, JSON and YAML handling, formatting, remote execution over SSH, file recovery, and shell-scripting conventions. The agent loads the short routing entry first and then only the one fragment the task needs, keeping context cost low. Every recipe relies on tools present by default on macOS and Linux (bash, python3, openssl, jq), so no external servers or extra dependencies are introduced.
-
verification-before-completion
A gate that forbids claiming work complete, fixed, or passing without fresh verification evidence alongside the claim. Before any status statement, commit, or pull request, the procedure identifies the command that would prove the claim, runs it in full, reads the whole output and exit code, and only then states the result together with the evidence. Regression tests must demonstrate a red-green cycle, delegated agent reports are verified against the actual diff, and in a shared working tree verification reads the committed state of the task branch, not another session's checkout.
-
visual-asset-direction
Inventories canonical assets and concepts, then records exactly one honest reuse/adapt/generate/reject decision per needed visual — preserving source revision, digest, license and provenance; distinguishing origin mechanically and disclosing it when it changes reader interpretation; delivering accessible localized briefs, responsive variants, alt and long-description obligations, and composition checks; prohibiting stock, generic filler, fake extraction, invented evidence, and low-quality synthetic diagrams.
-
visual-design-critique
How an agent judges a rendered surface rather than a stylesheet, and does it the same way twice. Carries a rule registry that is machine-readable and executed by a runner against the rendered page, so a critique is a set of findings with rule identities and measured values, not an opinion in prose. Each rule declares whether it is enforced or advisory, what it measures, and how it fails; a rule that cannot fail is not admitted to the registry. The registry deliberately covers what a token check cannot see — hierarchy, rhythm, density and composition — because the defect the customer actually reported was that the page reads like documentation, and no token value is wrong on such a page.