{
 "number": 36584,
 "input_hash": "607e5a20c98c5359",
 "model": "ledger",
 "prompt_hash": null,
 "created": "2026-10-22T01:17:25+00:00",
 "result": {
  "summary": "Replaces the public struct definition of `btck_LogEntry` in the libbitcoinkernel C API with an opaque handle and explicit getter functions (`btck_log_entry_get_*`). String fields are returned as non-owning `btck_StringView` structs rather than raw pointer and length pairs. Field values are extracted lazily upon access rather than eagerly converted before calling the registered logging callback.",
  "problem": "Exposing `btck_LogEntry` as a public C struct fixes its memory layout in the library ABI, preventing the addition or alteration of log fields without breaking backwards compatibility. It also deviates from almost all other libbitcoinkernel types, which use opaque handles.",
  "card": "Makes btck_LogEntry an opaque handle in the libbitcoinkernel C interface, exposing fields via btck_log_entry_get_* accessor functions. A public struct layout made it impossible to add or change log metadata fields without breaking ABI compatibility for kernel consumers, unlike other kernel API handles. Fields are now converted lazily when read, and author benchmarks show no meaningful performance impact (delta between -2.5 ns and +5.4 ns per log statement).",
  "evidence": [
   "Author note in description: 'This allows adding or changing fields without breaking the ABI, and is consistent with ~all other kernel objects. Follow-up to https://github.com/bitcoin/bitcoin/pull/34374#discussion_r4207440088.'",
   "Author microbenchmarks show negligible overhead: callback log statement duration shifts between \u22122.5 ns and +5.4 ns depending on how many fields are read."
  ],
  "scope_notes": "",
  "changed_since_previous": "Diff provided; matches the previous description.",
  "thread": {
   "last_event_at": "2026-10-21T10:31:07Z",
   "events": 4,
   "head_sha": "b2c077394a585a4155bd9d7a28b9b7c7553c9dc5",
   "schema_floor": 2,
   "schema": 2
  },
  "waiting_on": [
   {
    "at": null,
    "id": "",
    "on": "nothing",
    "url": null,
    "what": ""
   }
  ],
  "risk": {
   "level": "low",
   "touches": [
    "other"
   ],
   "why": "Mistakes are confined to libbitcoinkernel logging callback wrappers and getters, causing corrupted log fields or compilation issues for external kernel consumers."
  },
  "discussion": {
   "author_status": "last statement processed 2026-10-21",
   "open_concerns": [],
   "resolved_concerns": [
    "sedited: use one-line `///` descriptions for trivial getters (answered by stickies-v 2026-10-21)"
   ]
  },
  "reviewability": {
   "state": "Ready",
   "label": "Ready",
   "reason": "Nothing known that would invalidate a review now."
  },
  "agreement": {
   "state": "Strong",
   "summary": "Strong: substantive support, no open objection (musaHaruna)",
   "reason": "Initial record. sedited raised a style suggestion regarding docstring comments on getters, which the author answered, and both sedited and musaHaruna have ACKed the PR. / Initial record for the PR. sedited raised a minor docstring style suggestion which stickies-v answered, followed by ACKs from both sedited and musaHaruna.",
   "evidence": [
    "sedited: ACK",
    "musaHaruna: ACK \u2014 Tested locally, including calling all nine getters from the logging callback and checking the message, timestamp, source location, level, and category for the connection and disconnection messages."
   ],
   "objections": [
    {
     "reviewer": "sedited",
     "association": "MEMBER",
     "type": "suggestion",
     "kind": "style",
     "harm": "",
     "request": "use one-line `///` descriptions for trivial getters",
     "question": "",
     "text": "use one-line `///` descriptions for trivial getters",
     "clears_with": "answer",
     "blocking": false,
     "status": "answered",
     "status_note": "author replied preferring Doxygen docstring consistency across public functions, leaving as-is for now",
     "cleared": true,
     "author_replied": true,
     "others_replied": false,
     "fix_pushed": false,
     "replies": [
      "rc:4335706833"
     ],
     "evidence": "2026-10-21: 'Might a one-line `///` description be better for these trivial getters?'",
     "url": "https://github.com/bitcoin/bitcoin/pull/36584#discussion_r4335650884",
     "id": "rc:4335650884",
     "at": "2026-10-21",
     "status_at": "2026-10-21",
     "status_by": "stickies-v",
     "resolution_evidence": "2026-10-21: stickies-v: 'I personally prefer the consistency of using doxygen docstrings for all public functions, but don't care too strongly either way'",
     "pin": null,
     "from_schema": 2
    }
   ],
   "support": [
    {
     "reviewer": "sedited",
     "reason": "",
     "substantive": false,
     "verdict": "ACK",
     "id": "r:5598238408",
     "url": "https://github.com/bitcoin/bitcoin/pull/36584#pullrequestreview-5598238408",
     "at": "2026-10-21",
     "association": "MEMBER",
     "evidence": "none",
     "areas": []
    },
    {
     "reviewer": "musaHaruna",
     "reason": "Tested locally, including calling all nine getters from the logging callback and checking the message, timestamp, source location, level, and category for the connection and disconnection messages.",
     "substantive": true,
     "verdict": "ACK",
     "id": "r:5598343723",
     "url": "https://github.com/bitcoin/bitcoin/pull/36584#pullrequestreview-5598343723",
     "at": "2026-10-21",
     "association": "CONTRIBUTOR",
     "evidence": "tested",
     "areas": []
    }
   ],
   "participants": [
    {
     "login": "musaHaruna",
     "stance": "support",
     "note": "ACKed; tested getters and logging callback locally",
     "association": "CONTRIBUTOR",
     "comments": 1,
     "first": "2026-10-21",
     "last": "2026-10-21"
    },
    {
     "login": "sedited",
     "stance": "support",
     "note": "ACKed; suggested one-line comments for trivial getters",
     "association": "MEMBER",
     "comments": 2,
     "first": "2026-10-21",
     "last": "2026-10-21"
    }
   ],
   "derivation": "substantive support, no open objection (musaHaruna)",
   "model_state": null,
   "corrections": [],
   "notes": "Initial record. sedited raised a style suggestion regarding docstring comments on getters, which the author answered, and both sedited and musaHaruna have ACKed the PR. / Initial record for the PR. sedited raised a minor docstring style suggestion which stickies-v answered, followed by ACKs from both sedited and musaHaruna."
  },
  "dependencies": {
   "depends_on": [],
   "enables": []
  },
  "categories": [
   {
    "name": "kernel",
    "member": true,
    "evidence": "Modifies `src/kernel/bitcoinkernel.h`, `bitcoinkernel.cpp`, and `bitcoinkernel_wrapper.h` to change the public libbitcoinkernel C API logging interface.",
    "band": "P3",
    "reason_tag": "cleanup",
    "score": 0.4,
    "factors": {
     "bug_severity": 0,
     "leverage": 1,
     "performance": 0,
     "security_stability": 0,
     "user_value": 1
    },
    "rationale": "Making `btck_LogEntry` opaque aligns it with other kernel types and avoids fixing struct layout in the ABI. As the author notes, this 'allows adding or changing fields without breaking the ABI, and is consistent with ~all other kernel objects.' While it improves library ABI extensibility, the work is an internal C API refinement and reasonably deferrable."
   },
   {
    "name": "validation",
    "member": false,
    "evidence": "Despite the Validation label, the PR touches only `src/kernel/bitcoinkernel.*` C API files and alters no validation rules, chainstate handling, or consensus logic.",
    "band": "Unranked",
    "reason_tag": "cleanup",
    "score": 0.0,
    "factors": {
     "bug_severity": 0,
     "leverage": 1,
     "performance": 0,
     "security_stability": 0,
     "user_value": 1
    },
    "rationale": "Validation explicitly excludes PRs whose primary subject is the kernel library API. This PR changes only the public C API logging types and getters without affecting validation behavior."
   }
  ],
  "confidence": "high",
  "uncertainties": [],
  "needs": []
 },
 "cost_usd": 0.0,
 "source": {
  "record": "2026-10-22T01:17:25+00:00",
  "code": "2026-10-22T01:18:44+00:00",
  "judgments": 2
 }
}