approval-md 0.0.1 → 0.2.0

package/dist/src/channels/batch.d.ts

@@ -0,0 +1,109 @@
+/**
+ * Batching: one human gesture over many requests, without losing audit
+ * granularity (SPEC.md §10.3, requirement B7).
+ *
+ * > Channels MAY present multiple pending requests as a batch and collect one
+ * > human gesture over the set, and SHOULD for high-volume `record.*` classes.
+ * > The log never batches: each granted or rejected request receives its own
+ * > `approval.granted` or `approval.rejected` event carrying the batch's channel
+ * > delivery id in its payload, so audit granularity survives ergonomic
+ * > grouping. A batch MUST NOT mix `manual` classes with differing
+ * > payload-display requirements in a way that hides any full payload behind the
+ * > fold of another.
+ *
+ * Two halves, and this module is both: {@link assembleBatch} enforces the
+ * forbidden mix *before* anything is delivered, and {@link recordBatchDecisions}
+ * records one gate decision per member afterwards.
+ *
+ * ## The B7 operationalization — FLAGGED FOR HUMAN REVIEW
+ *
+ * "Hides any full payload behind the fold of another" is a sentence about
+ * rendering, and rendering is the one thing the runtime cannot inspect. So B7 is
+ * operationalized here as a property of the *batch material* rather than of the
+ * pixels:
+ *
+ * > A batch MUST carry every member's full payload whole. The forbidden mix is
+ * > any member whose `fullPayload` is absent or truncated while the batch
+ * > contains more than one distinct payload — because with one payload there is
+ * > no "another" to hide behind, and with two or more, a member the channel was
+ * > not given in full is a member the approver cannot have read.
+ *
+ * Concretely, {@link assembleBatch} refuses when the batch holds more than one
+ * distinct `payload_hash` **and** any member's `fullPayload` is `null` or
+ * `truncated`. A single-payload batch (the same bytes requested twice, or one
+ * request) is always assemblable, and a multi-payload batch is assemblable
+ * exactly when every member arrives whole.
+ *
+ * What this deliberately does **not** try to be: a judgment about whether a
+ * particular channel's layout actually put payload #2 below the fold. That is a
+ * per-channel rendering property, and `channels/conformance.ts` checks the
+ * observable half of it (every member's full payload text present in the
+ * rendering, delineated from the claimed summary). The interpretation to
+ * confirm is the reduction of "differing payload-display requirements" to
+ * "distinct payload bytes": it is the reading that makes the rule mechanical,
+ * and it is stricter than the spec's letter in one direction (two whole payloads
+ * are fine only if both are whole) and silent in another (it says nothing about
+ * a channel that renders both whole and then collapses one). A human should
+ * confirm this is the intended reading before APRV-23/25/26 build against it.
+ */
+import type { DecideOptions } from "../core/gate.js";
+import { type ChannelActorOptions, type ChannelBatch, type ChannelDecision, type ChannelRequest, type DecisionOutcome, type DeliveryId } from "./contract.js";
+export { BATCH_DELIVERY_ID_FIELD, BATCH_DELIVERY_NOTE_PREFIX, batchDeliveryIdOf, batchNote, type ChannelBatch, } from "./contract.js";
+/** The one way a batch can be refused (SPEC.md §10.3, B7). */
+export declare const BATCH_REFUSAL_CODE = "batch-forbidden-mix";
+export interface BatchRefusal {
+    ok: false;
+    code: typeof BATCH_REFUSAL_CODE;
+    message: string;
+}
+export type AssembleBatchResult = {
+    ok: true;
+    batch: ChannelBatch;
+} | BatchRefusal;
+/**
+ * Assemble `requests` into a batch, or refuse the forbidden mix.
+ *
+ * The returned batch carries every member request **whole** — the same
+ * {@link ChannelRequest} objects a channel would receive individually, tags and
+ * full payloads included. A channel therefore has everything it needs to render
+ * each member in full; if it chooses not to, that is a rendering defect the
+ * conformance suite catches, not a gap in the material it was handed.
+ *
+ * `deliveryId` is left unset: it is assigned by the channel at `notify`.
+ */
+export declare function assembleBatch(requests: ChannelRequest[]): AssembleBatchResult;
+/** One member's outcome. `token` is held back from the channel, as always. */
+export interface BatchMemberResult {
+    action_key: string;
+    outcome: DecisionOutcome;
+    /** The raw execution token for a successful grant. Runtime-only. */
+    token?: string;
+}
+export interface BatchDecisionsResult {
+    /** True when every member was recorded. */
+    ok: boolean;
+    /** One entry per input decision, in input order. */
+    results: BatchMemberResult[];
+    batchDeliveryId: DeliveryId;
+}
+/**
+ * Record one gate decision per batch member.
+ *
+ * **Unit decisions mean unit outcomes.** The log never batches (SPEC.md §10.3),
+ * so this is a loop over `decide()` and not a transaction: each member is
+ * checked and appended on its own, each carries the batch delivery id in its
+ * payload as the first-class `batch_delivery_id` field (amended SPEC.md §10.3,
+ * APRV-38), and a member that refuses does **not** stop the rest. That is
+ * deliberate and it is the only coherent semantics available — an "all or
+ * nothing" batch would have to un-append events the log forbids un-appending,
+ * and abandoning the remaining members because the third one expired would
+ * discard a human's answer to the other four. So: partial success is a real
+ * outcome, `ok` is false when any member refused, and `results` says exactly
+ * which ones landed. A caller that wants atomicity does not want a batch.
+ *
+ * Ordering: members are recorded in the order given. Each append passes the
+ * gate's compare-and-append precondition against the head *it* read, so a
+ * concurrent writer refuses one member with `append-failed`/`head-moved`
+ * rather than corrupting the set.
+ */
+export declare function recordBatchDecisions(logPath: string, decisions: ChannelDecision[], batchDeliveryId: DeliveryId, actorOptions: ChannelActorOptions, gateOptions?: DecideOptions): BatchDecisionsResult;

package/dist/src/channels/batch.js

@@ -0,0 +1,121 @@
+/**
+ * Batching: one human gesture over many requests, without losing audit
+ * granularity (SPEC.md §10.3, requirement B7).
+ *
+ * > Channels MAY present multiple pending requests as a batch and collect one
+ * > human gesture over the set, and SHOULD for high-volume `record.*` classes.
+ * > The log never batches: each granted or rejected request receives its own
+ * > `approval.granted` or `approval.rejected` event carrying the batch's channel
+ * > delivery id in its payload, so audit granularity survives ergonomic
+ * > grouping. A batch MUST NOT mix `manual` classes with differing
+ * > payload-display requirements in a way that hides any full payload behind the
+ * > fold of another.
+ *
+ * Two halves, and this module is both: {@link assembleBatch} enforces the
+ * forbidden mix *before* anything is delivered, and {@link recordBatchDecisions}
+ * records one gate decision per member afterwards.
+ *
+ * ## The B7 operationalization — FLAGGED FOR HUMAN REVIEW
+ *
+ * "Hides any full payload behind the fold of another" is a sentence about
+ * rendering, and rendering is the one thing the runtime cannot inspect. So B7 is
+ * operationalized here as a property of the *batch material* rather than of the
+ * pixels:
+ *
+ * > A batch MUST carry every member's full payload whole. The forbidden mix is
+ * > any member whose `fullPayload` is absent or truncated while the batch
+ * > contains more than one distinct payload — because with one payload there is
+ * > no "another" to hide behind, and with two or more, a member the channel was
+ * > not given in full is a member the approver cannot have read.
+ *
+ * Concretely, {@link assembleBatch} refuses when the batch holds more than one
+ * distinct `payload_hash` **and** any member's `fullPayload` is `null` or
+ * `truncated`. A single-payload batch (the same bytes requested twice, or one
+ * request) is always assemblable, and a multi-payload batch is assemblable
+ * exactly when every member arrives whole.
+ *
+ * What this deliberately does **not** try to be: a judgment about whether a
+ * particular channel's layout actually put payload #2 below the fold. That is a
+ * per-channel rendering property, and `channels/conformance.ts` checks the
+ * observable half of it (every member's full payload text present in the
+ * rendering, delineated from the claimed summary). The interpretation to
+ * confirm is the reduction of "differing payload-display requirements" to
+ * "distinct payload bytes": it is the reading that makes the rule mechanical,
+ * and it is stricter than the spec's letter in one direction (two whole payloads
+ * are fine only if both are whole) and silent in another (it says nothing about
+ * a channel that renders both whole and then collapses one). A human should
+ * confirm this is the intended reading before APRV-23/25/26 build against it.
+ */
+import { recordChannelDecision, } from "./contract.js";
+export { BATCH_DELIVERY_ID_FIELD, BATCH_DELIVERY_NOTE_PREFIX, batchDeliveryIdOf, batchNote, } from "./contract.js";
+// ---------------------------------------------------------------------------
+// assembleBatch
+// ---------------------------------------------------------------------------
+/** The one way a batch can be refused (SPEC.md §10.3, B7). */
+export const BATCH_REFUSAL_CODE = "batch-forbidden-mix";
+/**
+ * Assemble `requests` into a batch, or refuse the forbidden mix.
+ *
+ * The returned batch carries every member request **whole** — the same
+ * {@link ChannelRequest} objects a channel would receive individually, tags and
+ * full payloads included. A channel therefore has everything it needs to render
+ * each member in full; if it chooses not to, that is a rendering defect the
+ * conformance suite catches, not a gap in the material it was handed.
+ *
+ * `deliveryId` is left unset: it is assigned by the channel at `notify`.
+ */
+export function assembleBatch(requests) {
+    const hashes = new Set(requests.map((request) => request.payload_hash.value));
+    if (hashes.size > 1) {
+        const hidden = requests.filter((request) => {
+            const rendering = request.fullPayload.value;
+            return rendering === null || rendering.truncated;
+        });
+        if (hidden.length > 0) {
+            const keys = hidden.map((request) => request.action_key.value).join(", ");
+            return {
+                ok: false,
+                code: BATCH_REFUSAL_CODE,
+                message: `batch refused: it carries ${hashes.size} distinct payloads and ${hidden.length} member(s) whose full payload is absent or truncated (${keys}). SPEC.md §10.3 forbids a batch that hides any full payload behind the fold of another; a member the channel was never given in full is a member the approver cannot have read, so the set is refused before delivery rather than approved in part.`,
+            };
+        }
+    }
+    return { ok: true, batch: { requests } };
+}
+/**
+ * Record one gate decision per batch member.
+ *
+ * **Unit decisions mean unit outcomes.** The log never batches (SPEC.md §10.3),
+ * so this is a loop over `decide()` and not a transaction: each member is
+ * checked and appended on its own, each carries the batch delivery id in its
+ * payload as the first-class `batch_delivery_id` field (amended SPEC.md §10.3,
+ * APRV-38), and a member that refuses does **not** stop the rest. That is
+ * deliberate and it is the only coherent semantics available — an "all or
+ * nothing" batch would have to un-append events the log forbids un-appending,
+ * and abandoning the remaining members because the third one expired would
+ * discard a human's answer to the other four. So: partial success is a real
+ * outcome, `ok` is false when any member refused, and `results` says exactly
+ * which ones landed. A caller that wants atomicity does not want a batch.
+ *
+ * Ordering: members are recorded in the order given. Each append passes the
+ * gate's compare-and-append precondition against the head *it* read, so a
+ * concurrent writer refuses one member with `append-failed`/`head-moved`
+ * rather than corrupting the set.
+ */
+export function recordBatchDecisions(logPath, decisions, batchDeliveryId, actorOptions, gateOptions = {}) {
+    const results = [];
+    for (const decision of decisions) {
+        const recorded = recordChannelDecision(logPath, { ...decision, batchDeliveryId }, actorOptions, gateOptions);
+        results.push({
+            action_key: decision.action_key,
+            outcome: recorded.outcome,
+            ...(recorded.token === undefined ? {} : { token: recorded.token }),
+        });
+    }
+    return {
+        ok: results.every((entry) => entry.outcome.ok),
+        results,
+        batchDeliveryId,
+    };
+}
+//# sourceMappingURL=batch.js.map

package/dist/src/channels/batch.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"batch.js","sourceRoot":"","sources":["../../../src/channels/batch.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+CG;AAGH,OAAO,EACL,qBAAqB,GAOtB,MAAM,eAAe,CAAC;AAEvB,OAAO,EACL,uBAAuB,EACvB,0BAA0B,EAC1B,iBAAiB,EACjB,SAAS,GAEV,MAAM,eAAe,CAAC;AAEvB,8EAA8E;AAC9E,gBAAgB;AAChB,8EAA8E;AAE9E,8DAA8D;AAC9D,MAAM,CAAC,MAAM,kBAAkB,GAAG,qBAAqB,CAAC;AAUxD;;;;;;;;;;GAUG;AACH,MAAM,UAAU,aAAa,CAAC,QAA0B;IACtD,MAAM,MAAM,GAAG,IAAI,GAAG,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,OAAO,EAAE,EAAE,CAAC,OAAO,CAAC,YAAY,CAAC,KAAK,CAAC,CAAC,CAAC;IAE9E,IAAI,MAAM,CAAC,IAAI,GAAG,CAAC,EAAE,CAAC;QACpB,MAAM,MAAM,GAAG,QAAQ,CAAC,MAAM,CAAC,CAAC,OAAO,EAAE,EAAE;YACzC,MAAM,SAAS,GAAG,OAAO,CAAC,WAAW,CAAC,KAAK,CAAC;YAC5C,OAAO,SAAS,KAAK,IAAI,IAAI,SAAS,CAAC,SAAS,CAAC;QACnD,CAAC,CAAC,CAAC;QACH,IAAI,MAAM,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;YACtB,MAAM,IAAI,GAAG,MAAM,CAAC,GAAG,CAAC,CAAC,OAAO,EAAE,EAAE,CAAC,OAAO,CAAC,UAAU,CAAC,KAAK,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;YAC1E,OAAO;gBACL,EAAE,EAAE,KAAK;gBACT,IAAI,EAAE,kBAAkB;gBACxB,OAAO,EAAE,6BAA6B,MAAM,CAAC,IAAI,0BAA0B,MAAM,CAAC,MAAM,yDAAyD,IAAI,sPAAsP;aAC5Y,CAAC;QACJ,CAAC;IACH,CAAC;IAED,OAAO,EAAE,EAAE,EAAE,IAAI,EAAE,KAAK,EAAE,EAAE,QAAQ,EAAE,EAAE,CAAC;AAC3C,CAAC;AAsBD;;;;;;;;;;;;;;;;;;;GAmBG;AACH,MAAM,UAAU,oBAAoB,CAClC,OAAe,EACf,SAA4B,EAC5B,eAA2B,EAC3B,YAAiC,EACjC,WAAW,GAAkB,EAAE;IAE/B,MAAM,OAAO,GAAwB,EAAE,CAAC;IACxC,KAAK,MAAM,QAAQ,IAAI,SAAS,EAAE,CAAC;QACjC,MAAM,QAAQ,GAAG,qBAAqB,CACpC,OAAO,EACP,EAAE,GAAG,QAAQ,EAAE,eAAe,EAAE,EAChC,YAAY,EACZ,WAAW,CACZ,CAAC;QACF,OAAO,CAAC,IAAI,CAAC;YACX,UAAU,EAAE,QAAQ,CAAC,UAAU;YAC/B,OAAO,EAAE,QAAQ,CAAC,OAAO;YACzB,GAAG,CAAC,QAAQ,CAAC,KAAK,KAAK,SAAS,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,EAAE,KAAK,EAAE,QAAQ,CAAC,KAAK,EAAE,CAAC;SACnE,CAAC,CAAC;IACL,CAAC;IACD,OAAO;QACL,EAAE,EAAE,OAAO,CAAC,KAAK,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,OAAO,CAAC,EAAE,CAAC;QAC9C,OAAO;QACP,eAAe;KAChB,CAAC;AACJ,CAAC"}

package/dist/src/channels/cli.d.ts

@@ -0,0 +1,193 @@
+/**
+ * The CLI channel (APRV-23) — the zero-config channel, written against the
+ * contract in `channels/contract.ts` and nothing else.
+ *
+ * It is the first implementation of {@link TestableChannel}, and it exists as
+ * much to prove the contract is implementable as to be useful: a terminal has no
+ * stylesheet, no buttons and no webhook, so everything the contract asks a
+ * channel to do has to be done in plain text. If SPEC.md §9's display rule
+ * cannot survive a channel this poor, it cannot survive a rich one either.
+ *
+ * ## The rendering convention (SPEC.md §9)
+ *
+ * Every line carries a marker in the first column, and the marker is the first
+ * thing a reader sees:
+ *
+ * ```
+ * [computed] class            communicate.email.external            (log)
+ * [claimed]  summary          chase invoice 41                      (agent:drafter)
+ * ```
+ *
+ * `[computed]` means the runtime derived the value — from the verified log, the
+ * attested policy, the budget evaluator, the payload bytes, or arithmetic on the
+ * display instant — and the parenthetical names *which* derivation. `[claimed]`
+ * means the party under oversight wrote it, and the parenthetical names that
+ * party. The marker is not decoration: it is the difference between "the runtime
+ * says this is a manual action" and "an agent says this costs two cents", and a
+ * channel that gave them the same weight would be a conformance failure rather
+ * than a styling preference.
+ *
+ * Claimed lines are additionally indented under a `claimed by …` heading, so the
+ * split survives a terminal that eats no colour and a reader who skims. There is
+ * no bold, no colour and no unicode box drawing anywhere in this file — a marker
+ * a `less`, a pipe, a CI log or a screen reader can lose is a marker that was
+ * never there.
+ *
+ * ## The full payload (SPEC.md §10.4)
+ *
+ * For a manual action the payload is printed verbatim inside an explicitly
+ * delimited block:
+ *
+ * ```
+ * --- BEGIN FULL PAYLOAD (bound sha256 <hash>) ---
+ * { … }
+ * --- END FULL PAYLOAD ---
+ * ```
+ *
+ * The block is never mixed with the claimed summary, and the summary is never
+ * printed inside it. `channels/tagging.ts` has already checked those bytes
+ * against the recorded binding, so what is inside the delimiters is what the
+ * execution token will spend.
+ *
+ * ## What this file does NOT do
+ *
+ * It does not read the log, write the log, decide anything, or hold a token.
+ * The decision handler is registered by the runtime (`cli/channel.ts`) and its
+ * only job is to call {@link recordChannelDecision}. The prompt loop collects a
+ * gesture and hands it over; whether that gesture becomes an event is the gate's
+ * answer, not this file's.
+ *
+ * It also does not dispatch (APRV-55). This channel is **one-shot by design**:
+ * the runtime derives the queue once, renders it, collects decisions on the
+ * requests in front of the operator, and the process ends. There is no cycle in
+ * which a newly appended request could arrive, so there is nothing to push —
+ * the operator running the verb again is the refresh. Only the long-lived push
+ * channel (Telegram) needs a per-cycle send; the long-lived pull channel (web)
+ * re-derives per page view.
+ */
+import { type PromptLayout } from "../core/prompt-layout.js";
+import type { ChannelBatch, ChannelDecision, ChannelHealth, ChannelRequest, DecisionOutcome, DeliveryId, RenderedRequest, TestableChannel } from "./contract.js";
+/** The narrowest thing this channel needs to write to. `process.stdout` fits. */
+export interface OutputSink {
+    write(text: string): unknown;
+}
+/** The narrowest thing this channel needs to read lines from. `process.stdin` fits. */
+export type InputSource = NodeJS.ReadableStream;
+export interface CliChannelOptions {
+    /** Where the rendering goes. Defaults to `process.stdout`. */
+    output?: OutputSink;
+    /** Where the gesture comes from. Defaults to `process.stdin`. */
+    input?: InputSource;
+    /** Channel name recorded for audit. Defaults to `cli`. */
+    name?: string;
+    /**
+     * Which rows the rendering shows (APRV-218), from `channels.cli.prompt`.
+     *
+     * Resolved by the verb, which has already loaded the policy; this channel
+     * neither reads a policy file nor holds an opinion about what an operator
+     * should see. Defaults to {@link CLI_PROMPT_LAYOUT}, so a channel constructed
+     * without one renders exactly what it rendered before the key existed.
+     */
+    layout?: PromptLayout;
+}
+/** The marker prefixes. Exported because the help text and the tests pin them. */
+export declare const COMPUTED_MARKER = "[computed]";
+export declare const CLAIMED_MARKER = "[claimed]";
+/** The full-payload delimiters (SPEC.md §10.4). Pinned by tests. */
+export declare const PAYLOAD_BEGIN = "--- BEGIN FULL PAYLOAD";
+export declare const PAYLOAD_END = "--- END FULL PAYLOAD ---";
+/** One line of the legend, printed above every delivery. */
+export declare const RENDERING_LEGEND: string;
+/** What {@link CliChannel.collectDecision} produced. */
+export type CliCollection = {
+    kind: "decided";
+    decision: ChannelDecision;
+    outcome: DecisionOutcome;
+}
+/** The human declined to answer this one; nothing was reported. */
+ | {
+    kind: "skipped";
+}
+/** Input ended before an answer arrived; nothing was reported. */
+ | {
+    kind: "aborted";
+};
+export declare class CliChannel implements TestableChannel {
+    readonly name: string;
+    private readonly output;
+    private readonly input;
+    private handler;
+    private rendered;
+    private reader;
+    private counter;
+    /** The policy's row layout for this channel (APRV-218). Pure input to the rendering. */
+    private readonly layout;
+    constructor(options?: CliChannelOptions);
+    /**
+     * Present a request, or a batch, and return the delivery id.
+     *
+     * Writes to the output sink and nowhere else: no log, no state, no decision.
+     * A batch is rendered member by member — each member carries its own full
+     * payload, and folding one behind another is exactly what `channels/batch.ts`
+     * refuses upstream.
+     */
+    notify(request: ChannelRequest | ChannelBatch): DeliveryId;
+    onDecision(handler: (decision: ChannelDecision) => DecisionOutcome): void;
+    health(): ChannelHealth;
+    lastRendered(): RenderedRequest[];
+    /**
+     * Release the input interface. Safe to call when nothing was ever read.
+     *
+     * The source is paused as well as closed: a `readline` interface over
+     * `process.stdin` leaves the stream flowing, and a process that finished
+     * asking would sit there holding the event loop open.
+     */
+    close(): void;
+    /**
+     * The prompt loop: `g` grants, `r` rejects, `s` skips.
+     *
+     * A reject demands a note and re-asks until it gets one — a refusal an agent
+     * cannot read is a refusal it will retry. A grant's note is optional; there is
+     * nothing to explain about "yes, do the thing I was shown".
+     *
+     * The gesture is reported to the handler registered by the runtime, and the
+     * handler's {@link DecisionOutcome} is returned unchanged, refusals included.
+     * Nothing here inspects it, and nothing here retries: a gate refusal is an
+     * answer, and re-asking a human who already answered is how double-grants get
+     * made.
+     */
+    collectDecision(actionKey: string, deliveryId: DeliveryId, options?: {
+        batchDeliveryId?: DeliveryId;
+    }): Promise<CliCollection>;
+    /**
+     * The checkpoint prompt, in a terminal (APRV-257).
+     *
+     * The same question the Telegram tap asks, in the channel that has no
+     * buttons: the lines the runtime composed, then `s` to sign and `n` to
+     * decline. The text is the runtime's and identical on both surfaces, because
+     * the thing being consented to is identical and two phrasings of one gesture
+     * would be two claims about it.
+     *
+     * It collects a gesture and nothing else. What signing MEANS — the key, the
+     * head, the append — is the runtime's, exactly as a decision is: this channel
+     * can no more sign a checkpoint than it can grant a request.
+     *
+     * End of input is `null`, never a default. A closed pipe has not declined,
+     * and it certainly has not signed.
+     */
+    collectCheckpoint(lines: readonly string[]): Promise<boolean | null>;
+    private report;
+    /**
+     * Ask for a note. Returns `undefined` for "none given" and `null` when input
+     * ended — the two are different, and conflating them would let a closed pipe
+     * look like a human who chose to say nothing.
+     */
+    private askNote;
+    private readLine;
+    /**
+     * Build one request's rendering split. This is the same function whose output
+     * is written to the terminal — {@link lastRendered} is not a parallel
+     * description of the rendering, it *is* the rendering.
+     */
+    private renderRequest;
+}